Всем добрый день.

Имеется SIM800C, который раз в 5сек отсылает UDP пакет на сервер, на что сервер ему немедленно отвечает.
Большую часть времени работает стабильно, но иногда наблюдается такая картина:
-> модем отправил пакет
<- пришел ответ
-> модем отправил пакет
<- пришел ответ
-> модем отправил пакет
-> модем отправил пакет
-> модем отправил пакет
<- пришло сразу 3 пакета в одном

Сервер при этом пишет, что честно отправил ответ немедленно.
По потреблению модема видно, что все эти 15сек. данные действительно не приходят.

Такие дикие задержки на сети оператора? Или что-то еще?
Ладно бы задержки, но как разделять эти пакеты? Модем не дает никакой информации о том, где один пакет закончился и начался другой, выдает данные одним потоком. Может есть способ от модема добиться больше информации?
При этом непонятно - то ли пакеты склеились на стороне оператора (чего быть не должно), то ли пришли с таким коротким интервалом, что модем их выдал одним пакетом.

Оператор, конечно, может чудить, но в Вашем случае пока много неизвестных:
1. Что за сервер, на чем писан, как обрабатываются соединения.
2. 》 <- пришло сразу 3 пакета в одном - куда пришло 3-в-1? на сервер от модема? на модем от сервера?

Как закачиваются данные для передачи в SIM800C (через какой интерфейс) ?

1. Сервер под nodejs, но роли особой это не играет, т.к. я вижу что ответ уходит сразу (wireshark).
2. Имеется ввиду что пришел ответ от сервера. Т.е. ушло на сервер три пакета, а пришел один пакет(по крайней мере модем мне его отдает одним пакетом) с 3-мя ответами.

С модемом общаюсь через com-порт с аппаратным управлением потоком.

А каким образом пакет запроса "клиента"/Tx (то что закачивается в SIM через COM-порт) пакуется в UDP ?
Вообще, при передаче по сети возможна "переукладка" пакетов во фреймы с разным форматом, в том числе размером данных.
Если Вы работаете не в блочном режиме, а "потоком", то "слипание" это вполне закономерно.
Тк. формально тракт передачи для "потока" отработал нормально.
Надо также учитывать буферизацию на всех этапах.

В UDP пакует сам модем. Отсылаю стандартно, по команде AT+CIPSEND. Пакеты маленькие, меньше 30 байт

Скользкое место - это передача/прием по компорту в/из SIM.

1. Почему на модем передается 2 и 3 запрос, хотя на 1-ый запрос не пришел ответ.
2. Модем получил из сети ответы на 1,2,3 запросы (отдельно, в виде блоков-датаграмм UDP в контексте замечаний Сергей Борщ )
Клиент не успел считать первый ответ, и они (все 3 ответа) стали в "очередь" в SIM.
Далее - клиент начал читать данные из SIM. В очереди - 3 ответа. Как их считать "раздельно" через USART ?
Сейчас получается, что эти данные считываются из очереди "потоком", без выделения по пакетам UDP.

Надо курить настройки SIM и (возможно) работу с очередями, если таковые имеются.

Честно говоря, не понимаю, что вас удивляет? На мой взгляд нормальная ситуация.
Вы используете UDP, это протокол с негарантированной доставкой, как СОМ порт: послали данные, а дошли они или нет до адресата, протокол не гарантирует, это ваша забота.

У вас же каждые 5 сек отсылаются пакеты без ожидания ответа.
В расчете, что "ну уж за 5 секунд, они то дойдут". Откуда такая уверенность?
Я при отладке иногда наблюдал, что посланный по GPRS пакет доходил до сервера и обратно почти за 2 минуты

По поводу склеивания нескольких ответов - тоже нормально.
Протоколы группы TCP/IP не гарантируют, что адресату придет точно такой-же пакет с заголовками и прочим обрамлением, как вы послали. Гарантируется только, что придут ваши ДАННЫЕ. А они справно приходят.

Так что или ожидайте ответов на каждый запрос перед посылкой нового, или разбирайте пачки ответов на приеме.

Вот этот вопрос мне тоже интересен. То, что TCP может резать/клеить как угодно - известно всем. Потому что это потоковый протокол. И сосок (socket) под него открывается с параметром SOCK_STREAM. Здесь же речь идет об UDP, который по определению протокол передачи датаграмм. И Сосок открывается с параметром SOCK_DGRAM. Насколько я себе понимаю - датаграммы резать/клеить в пути никто не имеет права. И построенные поверх UDP протоколы (DHCP, DNS, NTP) поразумевают наличие определенных данных в определенных местах датаграммы.

А что, таймаут в 5 секунд недопустим? Ждать 5 минут ответа?






Имеют право или не имеют... Или просто имеют..
Лично наблюдал, когда ОпСоС менял несколько байтов в UDP пакете. При этом длина пакета не поменялась, UDP CRC верное....
Так что, теоретически, и склеить может как 2 пальца изолентой...

Наверное таки да, согласен, я писал применительно к ситуации топикстартера.
Он применяет встроенный стек модема, команду AT+CIPSEND, которая формирует UDP пакеты самостоятельно.
Она же их и принимает и вытаскивает из них данные. Поэтому на выходе модема пользователем уже получаются чистые данные БЕЗ обрамления пакета.

Для Daniil
Мы в таких случаях внутри своих данных применяем поле с номером пакета, при этом разбор пакетов не представляет сложности.


Зависит от задачи.
Если время есть, можно и подождать. А можно через некоторое время посылать повторы.
Но в этом случае разборщик ответов должен быть соответствующий.

Теоретически туристы могут писать на памятник Свободы в Риге, что они иногда и делают, несмотря на то, что это запрещено. Вы можете привести ссылку на конкретный стандарт, где написано, что склеивать UDP-пакеты можно?

Сергей Борщ, вот и я о том же, что ОпСоСы подобны упомянутым туристам. Ничего святого у них нет!

Я знаю что такое UDP и что доставка не гарантирована, но никак не рассчитывал что пакеты будут где-то ходить ТАК долго. Как вообще в таких условиях работают протоколы базирующиеся на UDP? Те же DNS, SNMP, NTP? Например, DNS клиент под винду ждет ответа 10сек (DNS Client от MS).

2 Baser
Поле с номером пакета у меня уже есть, но оно не спасает, т.к. изначально задумывалось, что ответы могут приходить разной длины. Теперь придется еще и длину пакета добавлять...

У оператора в приоритете номер один - обеспечение голосовой связи абонентов.
Затем - обеспечение работы ЕГО интернет-провайдера и любимых корпоративных клиентов (банки, платежные системы итп).
И только потом - все остальные смертные.
Так что сравнивать пользовательскую передачу данных и работу интернета даже у одного провайдера связи некорректно.

И даже у голоса 15 уровней приоритета

А с чего взяли, что склеивается именно на уровне UDP? Какой следующий уровень на сервере, который получает данные от UDP уровня? Как он обрабатывает данные? Подозреваю, что именно он и "чудит". Т.е. если у него в очереди несколько запросов (данных - payload'ов UDP), то он их обрабатывает скопом и кидает в выходную очередь, а та весь блок данных обрамляет в UDP пакет и отправляет на IP уровень и т.д. Вот дивайс и ловит "склеенные" ответы.

Нет, проблема не в сервере. Я смотрел трафик от него Wiresharkом - уходят именно отдельные пакеты. Остается два предположения - или они склеиваются на стороне оператора (что мне кажется маловероятным, но смущает очень большая задержка), или приходят с минимальным интервалом на сам модем, а он уже их выдает одним потоком. Как добиться от модема раздельной передачи принятых UDP - выяснить не удалось, в документации этот момент как-то обошли (или я не там смотрел).

99% проблема в операторе. Кто, кстати? Не Мегафон ли случаем?

МТС

Так, как идея - порт какой? Может сменить на другой.... Кто его знает, как там спецоборудование работает (от наших спецорганов).

Я думаю последнее, ничего нигде не склеивается, приходят на модем пачкой и он выдирает сам данные и выдает одним блоком.


Можете еще раз посмотреть "SIM800 Series_TCPIP_Application Note",
но там нет возможности читать из модема данные "по-пакетно", только просто есть суммарная длина данных, которые на данный момент лежат в приемном буфере модема. Причем именно уже ЧИСТЫХ данных, без обрамления.

Я эту проблему как-то решил изначально, на уровне структуры своих пакетов (данных) и включения заголовков для приема.
Пока применяю только AT+CIPHEAD=1, т.к. у меня обычно единственное подключение.
И разобрать свои данные на отдельные пакеты после +IPD (data length):
у меня не сложно.

Категорически не согласен. В данном случае оператор, как и слой UDP, не при чем.
Лично приходилось сталкиваться с описанным явлением на других модулях, тестировать и разбираться с механизмами эффекта.

Сервер, как и положено, отсылает три раздельных UDP ответа. Интернет, как и положено, направляет их на гейт сотового оператора (тут добавлю, что теоретически очередность ответов может измениться, но это бывает чрезвычайно редко, и все же их будет три). Сотовый оператор буферизирует ответы (по отдельности) и доставляет их на модуль. Если доставка сразу не удалась (сеть перегружена, модуль временно в "мертвой" зоне), попытки повторяются до тех пор, пока пакеты не будут доставлены. Именно тут формируется задержка в ситуации топикастера. Пакеты все же доставляются на модуль, но один за другим без пауз (но раздельно!), попадают в протокол TCP-стека, где буферизируются опять же раздельно. Затем модуль формирует URC и выдает результат. Вот тут они и склеиваются - из-за кривой реализации самого верхнего уровня - АТ-команд.

Вообще, работа со стеком через UART - зло. Используйте openAT, и получите несколько последовательных вызовов callback, что даст возможность зачитать пакеты раздельно. Используете внешний МК - перенесите часть логики в openAT, создав свои команды.
Не поленитесь освоить openAT: все будет просто, логично и избавит от львиной доли геморроя, постоянно поднимаемого в этой ветке форума, оно того стоит.

Спасибо за подробный ответ.
Да, я пришел к этому же выводу. Пакеты склеивает модем.
При отправке UDP пакетов с небольшим интервалом друг за другом ситуация со склеиванием на стороне модема воспроизводится почти 100%.
Пока решил проблему костылями. Уже была мысль перенести часть логики на модем, но такое решение мне не показалось удобным. Вариант со своим стеком нравится больше, правда в данном случае не подходит, т.к. ресурсы MCU его изначально не предусматривали.

У ТС'а UDP. Попыток доставить такой стек не делает. Пропал Никодим да и заголовок с ним.
Рекомендую посмотреть и показать журнал (например HHD Free Serial Port Monitor) обмена с модемом во время инициализации [модема] и процессе обмена данными. У меня такого поведения не было ни на телитах,
ни на симкомах. Тоже использую командный режим и маленькие пакеты.

Так и не понял из-за чего сыр-бор развели. С UDP я никгда не работал, но в TCP симком так себя ведет со времен царя гороха.
Если идут серьезные задержки, то модем потом одновременно выдает все данные которые к нему пришли.

Господа программисты! Где написано что модем должен выдавать данные в виде пакетов? Ткните пожалуйста в строку документации.

Представьте что ваши данные сыпятся через проводок по UART непрерывным потоком и без пауз. Протокол работает? Значит и через модем будет работать. Не работает? В топку.
Делайте протоколы которые из потока символов однозначно восстанавливают свои пакеты и будет вам счастье.

пс. Модемы telit в этом плане ведут себя ровно так же как и симком. Да и в описании других я никогда не встречал никаких пакетов.
Так что задумайтесь "на чьей стороне проблема"

Не ели UDP?Так зачем пытаетесь обсуждать его вкус?

Смотрим:

На русский перевести?

Да, автор не указал, какое значение у этой переменной.

Кстати, представители Симком может пояснят суть команды
8.2.25 AT+CIPUDPMODE UDP Extended Mode
?
Может в этом дело?

Даже комментировать не хочется. Внешние отличия TCP от UDP в стеке можно на пальцах одной руки перечислить.


А прочитать что там пониже в описании написано слабо? Или только название команды читаем? Или может на русский перевести?

Начинайте перечислять. Главное отличие уже было названо: TCP - потоковый протокол, UDP - протокол датаграмм (что следует из его названия). И именно это отличие запрещает модему дробить и склеивать UDP-пакеты (датаграммы), в отличие от TCP. "Я так думаю!".

Сергей Борщ, здесь обсуждается возможный косякособенность модема (коих у симкома хвататет). Так то понятно, склеивать-дробить не должен.

А что там пониже в описании? Можно и на английском и на китайском.

Прямо симпозиум писателей Читаем медленно по словам - "внешние", "в стеке".


Да пожалуйста:
Parameters
<mode> A numeric parameter which indicates whether an IP header is added to the received data or not.
0 Not add IP header
1 Add IP header, the format is:
1) For single IP connection (+CIPMUX=0)
+IPD,<data length>:
2) For multi IP connection (+CIPMUX=1)
+RECEIVE,<n>,<data length>:

Разверните свою мысль, пожалуйста. Я не нашел в исходном вашем сообщении этих слов.

Разворачиваю. Внутренности и особенности как UDP так и TCP скрыты от пользователя внутри стека. То что видно на вершине айсберга через AT - практически монопенисуарно.
Поведение естественно будет отличаться, но на уровне команд одно и то же. Не доверяете? Добро пожаловать в документацию


Исключено. Чтобы не наврать я как раз его скопировал и стер лишнее

Как тут выясняется, в документации каждый видит то, что хочет. Ибо, ее содержание (качество) позволяет это.

Вы вроде и русские слова используете, но я все равно не понимаю, что вы пытаетесь сказать. Пакеты UDP обязаны приходить отдельно. Если их склеивает модем - надо пинать производителя модема, а не пихать какие-то костыли поверх протокола.

Скопировал и его и еще предыдущее (т.е. оба два ваших сообщения на тот момент). Не знаю, что вы там стирали, но слов "внешние" и "в стеке" в них не находит даже мой текстовый редактор, а ему я доверяю. Выделите зеленым цветом:




И впредь будьте внимательнее, чтобы не сесть в лужу снова.

Вопрос который никто не задал.

Какой размер буфера указан под прием пакетов и какой длины сами пакеты ?
Попробуйте указать буфер таким чтобы он не вмещал 2 и более пакетов.

Вы (как и многие) хотите поиметь "на халяву" разбиение на пакеты. Это в корне неверно. Модем выдает данные (payload!). Уровень пакетов пользователю недоступен, и что самое главное - никто его и не обещал. Поэтому претензии к производителям совершенно безосновательны.
SOCKET в winapi работает точно так же - сколько данных упало, столько склеенных и на выходе. Где спрашивается шквал претензий к Билли?
Хотя я встречал негодование с квадратными глазами "а же я свои пакеты отличать один от другого буду"

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





Смело заявляю: этот текстовый редактор - г. Не доверяйте ему больше, а то неудобно получается.
Зеленый плохо заметно, синим лучше

Вы, похоже, снова смешали в кучу UDP и TCP. В UDP отдельные пакеты обещаны. Начало-конец датаграммы - такая же информация (payload!) как и все остальное ее содержимое.

Красный оставьте модераторам. И постарайтесь не нарушать п 2.1б Правил форума. Считайте это предупреждением.

Зря на коллегу нападаете, все он правильно написал.
Смешал в кучу UDP и TCP не он, а модемописальщики.
Речь то идет о надстройке над стеком, об АТ-командах.
При работе с этой надстройкой, действительно, нет никаких отличий в использовании UDP или TCP.
Никакое обрамление пакетов стека на входе/выходе недоступно, только голые данные.
Будете смеяться, даже установление CONNECT-а одинаково и он также присутствует даже при наличии UDP.
И закрывать этот UDP connect тоже нужно

Я так и не понял, какая между ними разница со стороны модема. Траффик больше (может быть, не проверял )

А по изначальному вопросу топикстартера, так вроде бы уже все подробно разжевали...

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


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

В UDP - само собой. Но речь то идет о модеме и его командах. На этом уровне и самого понятия "пакет" уже нет, все зарыто унутре.


Это справедливо для любой инкапсуляции, все что было выше - payload. И самый самый самый верхний это пользовательские данные. Модем их и выдает, наичестнейшим образом на который способен.


Во, еще одно неудобство как с зеленым. Чуть мозг не сломал где 2-шестнадцать.
Яволь! Красный уже не нужен, меняю на другой. Слова тоже сейчас подчищу




ПК не мой профиль, для мох убогих програмулек хватало тупого поллинга и send/recv. И я никому ничего не советую и своего бесценного мнения не навязываю. В отличие от "больших" программистов, которые приходя в чужой монастырь рассказывают как тут все неудобно и сделано через одно место.

Что покажет сообщение об изменении? Факт прихода данных? Их количество в буфере?


Ок, модем клеит пользовательские данные. И при плохой связи делает это довольно часто. Понять и простить.
Вот это и будет самый короткий и точный ответ на вопрос топикстартера.

Кое какое, вроде как доступно. Хотя бы длинна. Повторюсь:

8.2.15 AT+CIPHEAD Add an IP Head at the Beginning of a Package Received

То есть вроде как IP заголовок и пакета. Хотя, эти китайцы такие китайцы. Вполне возможно, это сложности перевода.


Я долго репу чесал после ответа китайца (магазин таобао)

Естественно, я пользуюсь гуглопереводчиком. И предпочитаю с Китайского на Английский.
不客气 - blunt - дурак.
Только вот на Руссккий гугл переводит иначе:
不客气 - Добро пожаловать

не просто навязываете, а ещё игнорируете факты. ведёте себя на полпсаки. что чести вам не делает.


это вам всёравно не интересно. нет смысла распинаться.



срач вообще ни о чём без данных от ТСа. Его попросили предоставить журнал обмена с временными метками и где он? У него аппаратное управление потоком и какая-то программулька на ПК.
Может он RTS/CTS'ом не умеет пользоваться, может CIPRXGET вызывает раз в час. Т.е. доказательств отсутствия ошибки ТСа нет. Развели балаган. Книжки читайте, да хоть вики.

Ну да. Длина пользовательский данных, куда же без этого.


Ага, ага Все так только имелся ввиду не IP пакет а IP стек. А под Package имелись ввиду строки которые модем вываливает.


Или китайского английского


Насколько помню то китайвед говорил что одинаковые по звучанию слова имею разное значение от многих факторов.
Вывод - гуглопереводчик разные люди с разным настроением делали


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


Можно я сам решу интересно или нет? Форум это общественное место, ответы читаю не только я.
Этом момент интересен хотя бы понять стоит ли вобще копать в ту сторону или ничего потенциально полезного там нет.


Да ни к чему оно. Проблема и выеденного яйца не стоит. "Стек модема" не тождественно "протокол UDP". И точка.

улыбнуло. это как: производители USB-флешек не обязаны соблюдать спецификации USB.


да решайте. всё уже написано, по несколько раз писать одно и тоже не интересно.

ТС был 28.11, ставлю 50 г вискаса, что затуп в алгоритмах ТСа )


это когда чукча не читатель, а писатель, то ничего не понятно. А если открыть AT_Command_Manual и сложить буквы в слова, то сразу становится понятно, что делает эта команда.


это когда чукча не читатель, а писатель, то ничего не понятно. А если открыть AT_Command_Manual и сложить буквы в слова, то сразу становится понятно, что делает эта команда.

Stream в TCP несет смысл тот, что пакеты будут доставлены ровно в том порядке, в каком ушли, то есть последовательность (поток, stream) сохранится, и это гарантирует протокол TCP.
Datagram в UDP несет смысл тот, что пакеты будут отправлены ровно в том порядке и так, как их нарезал (на датаграммы) отправитель. В каком порядке они придут получателю, и придут ли вообще - протокол не гарантирует. Поэтому требовать от него, чтобы он ещё и отдавал их раздельно - перебор.
А если у получателя нет даже буфера такого размера, чтобы принять весь пакет? Что, нельзя уже из UDP-сокета 4 байта прочитать? Только весь пакет?
А если можно 4 байта - что будет с недочитанным пакетом при следующем чтении recv()?

Т.е. если

то это означает, что UDP не поддерживается.

В контексте модема (я надеюсь мы все таки обсуждаем здесь именно модемы?) если "получатель" прочитать как "юзер", то это значит что юзеру и не нужны все данные из пакета одним махом. Он их замечательно вычитает теми порциями которые пролезут в буфер. А вот сам стек будет поддерживать и правильный прием, и возможно что и внутрений буфер для данных будет куда больше 1432.
И UDP поддерживается, и TCP, и у юзера хитреца эдакого буфер маленький!


Согласно вашей логике правильнее так:
а) поддерживается спецификация USB в достаточном для функционирования объеме
б) на уровне файловой системы у вас нет совершенно никакого доступа к его пакетам и процессам.
Вывод - USB не поддерживается, ведь нет низкоуровневого доступа.


Я все таки настаиваю. Тычек в название доки и раздел где это описано. Не в том плане что мне лень, могу ведь промахнуться


Затуп у него 99% в протоколе - рассчет на то что пакеты будут приходить по отдельности и данные будут вылезать такими же порциями, где порция = данные строго одного пакета. Сидит и перекраивает. Или свой стек поднимает.

хотите научить - учите. поучать не надо. был конкретный вопрос и очень важный,


вы даже не видите того, что не увидели. не то, что неинтересно, а нудно и расстраивает. если интересно - читайте ветку по новой, конспектируйте.