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

И даже у голоса 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. "Я так думаю!".