Странный глюк SIM300D, SIM300D "глотает" данные Опции

[sz36]

Hi, All!

Столкнулся со странным глюком SIM300D. Использую GPRS для получения данных по HTTP. Алгоритм простейший - один GET, запрашивающий файл, и прием этого файла. На файлах, не превышающих несколько кб все хорошо, но когда получаю файл большего размера, то в принятом файле оказываются пропущенные куски по несколько сот байт на каждые несколько принятых килобайт. Пропуски в разных местах, но первый всегда примерно на одном и том же месте, после пятого принятого килобайта.

Чтобы исключить собственные ошибки, продублировал прием внешней терминальной программой - тоже самое, a принятом файле, в сравнении с исходным, есть пропуски. Почему так? Сеанс связи завершается нормально, никаких разрывов связи или ошибок нет.

Возникла версия, что размер буфера в TCP стеке SIM300 слишком мал, и он захлебывается принимаемым файлом. А выбирать данные быстрее я не могу, ибо данные - это прошивка, и во время приема она пишется в память программ (AVR). Поэтому прием данных в МК все время тормозится с помощью RTS, чтобы успевать записывать. Сомнительная версия, но другой у меня нет... Еще версия, что в принимаемых данных (они двоичные) встречается какая-то неудачная комбинация, от которой SIM300 дуреет. Но тогда ошибка была всегда точно в одном и том же месте, а она немного плавает.

В чем может быть дело, кто-нибудь сталкивался с подобным? Есть ли у SIM300D возможность посмотреть состояние TCP стека, или отрегулировать какие-нибудь параметры (размер буфера, и др)?

[CADiLO]

>>>> И выходной поток притормаживался? Не верю. Проблема не в том, чтобы прогнать мегабайт, а чтобы принять его с необходимой скоростью.

Это вам не проводные сети точка-точка. Тут все от оператора зависит. Вы примете свой мегабайт или сколько там, с той скоростью, которую посчитает нужным предоставить оператор. И если в некий момент будет перегруз канала по разговорам, то будете сидеть и ждать с нулевой скоростью. Данные в сотовых сетях передаются по остаточному принципу, приоритет отдается разговорам.
Поэтому используем RTS-CTS чтобы видеть что сота не отдает данные или не принимает их от вас.

Так что принимать и писать "на лету" есть глупость. Принимаем в буфер, желательно с КС, а потом только обновляемся.

[sz36]

Это вам не проводные сети точка-точка. Тут все от оператора зависит. Вы примете свой мегабайт или сколько там, с той скоростью, которую посчитает нужным предоставить оператор. И если в некий момент будет перегруз канала по разговорам, то будете сидеть и ждать с нулевой скоростью. Данные в сотовых сетях передаются по остаточному принципу, приоритет отдается разговорам.
Поэтому используем RTS-CTS чтобы видеть что сота не отдает данные или не принимает их от вас.

Так что принимать и писать "на лету" есть глупость. Принимаем в буфер, желательно с КС, а потом только обновляемся.

Э-э-э, Вы это зачем написали? Какое отношение написанное имеет к означенной проблеме? В данной дискуссии Вы вообще какую точку зрения отстаиваете?

Что описанного явления не существует? Так Ваша позиция тогда, мягко говоря, весьма шаткая. Ибо явление элементарно воспроизводится. Берем SIM300 с любой терминальной программой. Настраиваем: включаем аппаратное управление потоком, прозрачный режим данных и все что нужно. Через CIPSTART подключаемся к любому Web-серверу на 80 порту. Набираем команду GET и запрашиваемм какой-нибудь файл подлиннее, лучше текстовой. Например Анну Каренину, не забыв добавить Keep-Alive. Предварительно в свойствах терминала ставим CR+LF как конец строки. После двойного нажатия Enter по экрану побегут бессмертные строки. Пока все очень хорошо. Включаем сохранение лога в файл. И затем снимаем RTS. Строчки на экране остановились, это тоже правильно. Подождав секунд 30 снова включаем RTS, строчки вновь побежали. На первый взгляд все замечательно, но если теперь не полениться и сравнить текст, оставшийся в логе, с каноническим, то мы обнаружем в нем лакуну, чуть позже того места, где мы снимали RTS.
Ваше объяснение полученных результатов?

А может Вы полагаете, что описанное явление не баг, а фича? Что ж, это вопрос диалектический. Лично я полагаю, что баг, но готов допустить, что Вы считаете по другому. Я бы согласился, что фича, если модем хотя бы сообщение об ошибке (переполнение буфера) выдавал, а то ведь нет, он считает что все в порядке - что принял, то и отдал! А ведт TCP обязан гарантировать целостность принятых данных. Или, если бы он, не обращая внимания на RTS, все равно бы данные выплевывал, дескать девать некуда. А молча глотать - это все-таки баг. Или, как минимум, ограничение данной реализации TCP стека. Собс-но, совершенно не важно как явление квалифицирую я или Вы, гораздо интереснее, знают ли о таком поведении в SimCom, и как явление квалифицируют там. Не исключено, что проблема уже пофиксена, мне проверять лень, ибо для себя я вопрос решил описанным выше способом, а что там думает SimCom меня мало волнует на данном отрезке времени. И вообще, по моему скромному мнению, повышение юзабельности SIM300 и расширение его области применения много больше должно волновать его изготовителя и дистрибьютеров, нежели меня. Я то, если будет совсем плохо, могу и другие модемы использовать.

А если Вы решили поучить меня проектированию, как надо строить архитектуру системы, то я Вам, конечно, жутко признателен, но, тем не менее, оставляю за собой право проектировать так, как считаю нужным, и класть на Ваши советы. Во всяком случае, на советы подобного уровня.

Странные люди... Казалось бы, проблема - выявлена, исследована, локализована. Найдено обходное решение (устраивающее, по крайней мере, меня). Так нет - несут какую-то ахинею... питание... мегабайты принимал... глупость писать на лету... И уж полным откровением для меня было, что КС надо к файлу добавлять, оказывается! Дескать, тогда в модеме переполнения буфера не случается! Я, например, считаю глупостью помещение подобного рода сообщений на форум.