[Daniil 2]

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

 

Имеется SIM800C, который раз в 5сек отсылает UDP пакет на сервер, на что сервер ему немедленно отвечает.

Большую часть времени работает стабильно, но иногда наблюдается такая картина:

-> модем отправил пакет

<- пришел ответ

-> модем отправил пакет

<- пришел ответ

-> модем отправил пакет

-> модем отправил пакет

-> модем отправил пакет

<- пришло сразу 3 пакета в одном

:smile3046:

Сервер при этом пишет, что честно отправил ответ немедленно.

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

 

Такие дикие задержки на сети оператора? Или что-то еще?

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

При этом непонятно - то ли пакеты склеились на стороне оператора (чего быть не должно), то ли пришли с таким коротким интервалом, что модем их выдал одним пакетом.

[Alechek 0]

Оператор, конечно, может чудить, но в Вашем случае пока много неизвестных:

1. Что за сервер, на чем писан, как обрабатываются соединения.

2. 》 <- пришло сразу 3 пакета в одном - куда пришло 3-в-1? на сервер от модема? на модем от сервера?

[k155la3 26]

. . . .

Имеется SIM800C, который раз в 5сек отсылает UDP пакет на сервер, на что сервер ему немедленно отвечает.

. . . .

При этом непонятно - то ли пакеты склеились на стороне оператора (чего быть не должно), то ли пришли с таким коротким интервалом, что модем их выдал одним пакетом.

 

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

 

[Daniil 2]

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

2. Имеется ввиду что пришел ответ от сервера. Т.е. ушло на сервер три пакета, а пришел один пакет(по крайней мере модем мне его отдает одним пакетом) с 3-мя ответами.

 

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

[k155la3 26]

. . . .

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

А каким образом пакет запроса "клиента"/Tx (то что закачивается в SIM через COM-порт) пакуется в UDP ?

Вообще, при передаче по сети возможна "переукладка" пакетов во фреймы с разным форматом, в том числе размером данных.

Если Вы работаете не в блочном режиме, а "потоком", то "слипание" это вполне закономерно.

Тк. формально тракт передачи для "потока" отработал нормально.

Надо также учитывать буферизацию на всех этапах.

 

 

 

 

[Daniil 2]

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

[Сергей Борщ 119]

Если Вы работаете не в блочном режиме,

UDP (англ. User Datagram Protocol — протокол пользовательских датаграмм)

Датаграмма (англ. datagram, дейтаграмма) — блок информации, передаваемый протоколом без предварительного установления соединения и создания виртуального канала

 

[k155la3 26]

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

 

1. Почему на модем передается 2 и 3 запрос, хотя на 1-ый запрос не пришел ответ.

2. Модем получил из сети ответы на 1,2,3 запросы (отдельно, в виде блоков-датаграмм UDP в контексте замечаний Сергей Борщ )

Клиент не успел считать первый ответ, и они (все 3 ответа) стали в "очередь" в SIM.

Далее - клиент начал читать данные из SIM. В очереди - 3 ответа. Как их считать "раздельно" через USART ?

Сейчас получается, что эти данные считываются из очереди "потоком", без выделения по пакетам UDP.

 

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

 

 

 

 

[Baser 5]

Имеется SIM800C, который раз в 5сек отсылает UDP пакет на сервер, на что сервер ему немедленно отвечает.

Большую часть времени работает стабильно, но иногда наблюдается такая картина:

...

 

<- пришло сразу 3 пакета в одном

 

Сервер при этом пишет, что честно отправил ответ немедленно.

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

 

Такие дикие задержки на сети оператора? Или что-то еще?

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

При этом непонятно - то ли пакеты склеились на стороне оператора (чего быть не должно), то ли пришли с таким коротким интервалом, что модем их выдал одним пакетом.

Честно говоря, не понимаю, что вас удивляет? На мой взгляд нормальная ситуация.

Вы используете UDP, это протокол с негарантированной доставкой, как СОМ порт: послали данные, а дошли они или нет до адресата, протокол не гарантирует, это ваша забота.

 

У вас же каждые 5 сек отсылаются пакеты без ожидания ответа.

В расчете, что "ну уж за 5 секунд, они то дойдут". Откуда такая уверенность?

Я при отладке иногда наблюдал, что посланный по GPRS пакет доходил до сервера и обратно почти за 2 минуты :)

 

По поводу склеивания нескольких ответов - тоже нормально.

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

 

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

[Сергей Борщ 119]

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

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

[Alechek 0]

У вас же каждые 5 сек отсылаются пакеты без ожидания ответа.

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

 

 

 

 

 

Здесь же речь идет об UDP, который по определению протокол передачи датаграмм. И Сосок открывается с параметром SOCK_DGRAM. Насколько я себе понимаю - датаграммы резать/клеить в пути никто не имеет права.

Имеют право или не имеют... Или просто имеют..

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

Так что, теоретически, и склеить может как 2 пальца изолентой...

[Baser 5]

Насколько я себе понимаю - датаграммы резать/клеить в пути никто не имеет права. И построенные поверх UDP протоколы (DHCP, DNS, NTP) поразумевают наличие определенных данных в определенных местах датаграммы.

Наверное таки да, согласен, я писал применительно к ситуации топикстартера.

Он применяет встроенный стек модема, команду AT+CIPSEND, которая формирует UDP пакеты самостоятельно.

Она же их и принимает и вытаскивает из них данные. Поэтому на выходе модема пользователем уже получаются чистые данные БЕЗ обрамления пакета.

 

Для Daniil

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

 

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

Зависит от задачи.

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

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

[Сергей Борщ 119]

Так что, теоретически, и склеить может как 2 пальца изолентой...

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

[Alechek 0]

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

[Daniil 2]

Честно говоря, не понимаю, что вас удивляет? На мой взгляд нормальная ситуация.

Вы используете UDP, это протокол с негарантированной доставкой, как СОМ порт: послали данные, а дошли они или нет до адресата, протокол не гарантирует, это ваша забота.

 

У вас же каждые 5 сек отсылаются пакеты без ожидания ответа.

В расчете, что "ну уж за 5 секунд, они то дойдут". Откуда такая уверенность?

Я при отладке иногда наблюдал, что посланный по GPRS пакет доходил до сервера и обратно почти за 2 минуты :)

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

 

2 Baser

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