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

Имеется 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
Поле с номером пакета у меня уже есть, но оно не спасает, т.к. изначально задумывалось, что ответы могут приходить разной длины. Теперь придется еще и длину пакета добавлять...