Склеиваются UDP пакеты Опции

[Daniil]

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

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

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

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

[Alechek]

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

[k155la3]

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

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

[Daniil]

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

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

[k155la3]

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

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

[Daniil]

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

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

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

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

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

[k155la3]

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

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

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

[Baser]

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

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

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

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

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

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

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

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

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

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

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

[Alechek]

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

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

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

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

[Baser]

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

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

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

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

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

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

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

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

[Alechek]

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

[Daniil]

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

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

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

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

[k155la3]

. . . . но никак не рассчитывал что пакеты будут где-то ходить ТАК долго.
. . . .

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

[Alechek]

У оператора в приоритете номер один - обеспечение голосовой связи абонентов.

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

[dxp]

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

[Daniil]

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

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

[Alechek]

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

[Daniil]

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

МТС

[Alechek]

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

[Baser]

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

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

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

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

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

[GeGeL]

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

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

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

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

[Daniil]

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

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

[smalcom]

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

[butthead2]

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

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

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

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

[Alechek]

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

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

Смотрим:

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

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

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

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

[butthead2]

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

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

8.2.15 AT+CIPHEAD Add an IP Head at the Beginning of a Package Received
На русский перевести?

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

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

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

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

[Alechek]

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

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

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

[butthead2]

Начинайте перечислять. Главное отличие уже было названо: 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>:

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

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

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

[butthead2]

Разверните свою мысль, пожалуйста.

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

Я не нашел в исходном вашем сообщении этих слов.

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

[Alechek]

Не доверяете? Добро пожаловать в документацию

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

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

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

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

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

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

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

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

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

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

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

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

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

[CADiLO]

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

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

[butthead2]

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

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

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

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

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

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

Сообщение отредактировал butthead2 - Nov 30 2016, 19:13

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

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

SOCKET в winapi работает точно так же - сколько данных упало, столько склеенных и на выходе. Где спрашивается шквал претензий к Билли?

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

Зеленый плохо заметно, красным лучше

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

[Baser]

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

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

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

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

[smalcom]

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

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

Смешал в кучу UDP и TCP не он, а модемописальщики.

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

[butthead2]

Вы, похоже, снова смешали в кучу UDP и TCP. В UDP отдельные пакеты обещаны.

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

Начало-конец датаграммы - такая же информация (payload!) как и все остальное ее содержимое.

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

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

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

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

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

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

да не клеит модем пакеты.

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

[Alechek]

Никакое обрамление пакетов стека на входе/выходе недоступно, только голые данные.

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

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

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


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

不客气

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

[smalcom]

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

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

Что покажет сообщение об изменении?

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



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

[butthead2]

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

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

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

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

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

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

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

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

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

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

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

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

срач вообще ни о чём без данных от ТСа. Его попросили предоставить журнал обмена с временными метками и где он? У него аппаратное управление потоком и какая-то

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

[smalcom]

"Стек модема" не тождественно "протокол UDP". И точка.

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

Можно я сам решу интересно или нет?

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

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

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

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

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

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

[gerber]

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

[smalcom]

На практике также следует учитывать, что если длина IPv4 пакета с UDP будет превышать MTU (для Ethernet по умолчанию 1500 байт), то отправка такого пакета может вызвать его фрагментацию, что может привести к тому, что он вообще не сможет быть доставлен, если промежуточные маршрутизаторы или конечный хост не будут поддерживать фрагментированные IP пакеты. Также в RFC 791 указывается минимальная длина IP пакета 576 байт, которую должны поддерживать все участники, и рекомендуется отправлять IP пакеты большего размера только в том случае если вы уверены, что принимающая сторона может принять пакеты такого размера. Следовательно, чтобы избежать фрагментации UDP пакетов (и возможной их потери), размер данных в UDP не должен превышать: MTU — (Max IP Header Size) — (UDP Header Size) = 1500 — 60 — 8 = 1432 байт. Для того чтобы быть уверенным, что пакет будет принят любым хостом, размер данных в UDP не должен превышать: (минимальная длина IP пакета) — (Max IP Header Size) — (UDP Header Size) = 576 — 60 — 8 = 508 байт.

Т.е. если

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

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

[butthead2]

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

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

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

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

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

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

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

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

[smalcom]

Затуп у него 99% в протоколе

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

Я все таки настаиваю.

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

[butthead2]

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

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

вы даже не видите того, что не увидели.

Интересная логическая конструкция, я в замешательстве.
Я вижу редкие вкрапления толковых постов по теме + три страницы обсасывания особенностей протокола UDP.
Знакомое слово "UDP", понеслась! Кривая реализация стека, ату его ату!

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

Понятно, ответа нет. Вы и вопрос скорее всего не читали, к ветке он не относится.

[smalcom]

Так и не понял из-за чего сыр-бор развели. С UDP я никгда не работал

спец

[Daniil]

У него аппаратное управление потоком и какая-то программулька на ПК

"Программулька" не на ПК, с модемом работает микроконтроллер, но не думаю что это что-то меняет.

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

RTS/CTS'ом пользоваться умею, пробовал временно отключать, ситуация та же.
Принятый пакет ловлю по URC, кроме того идет постоянный вызов CIPRXGET с небольшим (снижал до 1сек) интервалом (на случай если вдруг что пропустил). Помимо всего прочего, я смотрел напрямую данные с модема на ПК (пока он общается с контроллером), URC реально не приходит. Логи пока предоставить не могу, по техническим причинам.

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

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

2 smalcom
Я правильно понимаю, что вы пытаетесь сказать что проблема у меня, а модем работает как положено, выдавая все принятые данные по UDP одним потоком, как в TCP?

[Alechek]

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

Вот тут попрошу без оскорблений. Мне наср@ать что делает эта команда. Но из названия следует, что модем при использовании этой команды все-таки работает с пакетами. И ее описание дальнейшее этому не противоречит.

Daniil, настойки модема скажите. А то тут клавиатуру скоро все сломают и в рукопашную перейдут !
Достаточно команды AT+CIPSCONT? после всех инициализаций.

[smalcom]

Я правильно понимаю, что вы пытаетесь сказать что проблема у меня, а модем работает как положено, выдавая все принятые данные по UDP одним потоком, как в TCP?

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

ведь для

идет постоянный вызов CIPRXGET

тоже надо настраивать модем. А как вы его настраиваете неизвестно - нет журнала.

--------

Мне наср@ать что делает эта команда.

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

[Daniil]

2 Alechek

Код

AT+CIPSCONT?
+CIPSCONT: 1
+CIPCSGP: 1
Gprs Config APN: internet.mts.ru
Gprs Config UserId: mts
Gprs Config Password: mts
+CIPHEAD: 0
+CIPSHOWTP: 0
+CIPSRIP: 0
+CIPATS: 0,0
+CIPSPRT: 1,0
+CIPQSEND: 0
+CIPMODE: 0
+CIPCCFG: 5,2,1024,1,0,1460,50
+CIPMUX: 1
+CIPDPDP: 1,10,3
+CIPRXGET: 1
+CIPRDTIMER: 2000,3500

тоже надо настраивать модем. А как вы его настраиваете неизвестно - нет журнала

В чем там настройка? Автоматчиеский / ручной режим приема, другого я не вижу (я про CIPRXGET).
Журнал модема мне пока недоступен, т.к. модем физически далеко. Доступна только отладочная консоль.
Есть инициализация из старого лога, особо ничего не менял.

Код

AT
OK
AT+CSMINS?
+CSMINS: 0,1

OK
ATE1
OK
AT+IFC=2,2
OK
AT+CFUN=1
OK

+CPIN: READY
AT+CPIN?
+CPIN: READY

OK
AT+GSMBUSY=1
OK
AT+CREG?
+CREG: 0,2

OK
AT+CREG?
+CREG: 0,2

OK

Call Ready
AT+CREG?
+CREG: 0,2

OK

SMS Ready
AT+CREG?
+CREG: 0,1

OK
AT+CGATT?
+CGATT: 0

OK
AT+CGATT?
+CGATT: 1

OK
AT+CIPRXGET=1
OK
AT+CIPMUX=1
OK
AT+SAPBR=3,1,"CONTYPE","GPRS"
OK
AT+CSTT="internet.mts.ru","mts","mts"
OK
AT+SAPBR=3,1,"APN","internet.mts.ru"
OK
AT+SAPBR=3,1,"USER","mts"
OK
AT+SAPBR=3,1,"PWD","mts"
OK
AT+CIICR
OK

[Alechek]

Daniil, вариантов я вижу 3:

1. Действительно ли надо вручную выгребать данные? Попробуйте работать с +CIPRXGET=0. При заборе данных в ручном режиме никаких упоминаний про пакеты нет.
2. Установите +CIPHEAD=1
3. Попробуйте работать без режима мультиплексора +CIPMUX=0

В Вашем случае и с Вашими настройками вполне допускаю, что пакеты в данные склеивает модем.

[Daniil]

Daniil, вариантов я вижу 3:

1. Действительно ли надо вручную выгребать данные? Попробуйте работать с +CIPRXGET=0. При заборе данных в ручном режиме никаких упоминаний про пакеты нет.
2. Установите +CIPHEAD=1
3. Попробуйте работать без режима мультиплексора +CIPMUX=0

В Вашем случае и с Вашими настройками вполне допускаю, что пакеты в данные склеивает модем.

1. Прямой необходимости нет, просто это позволяет контролировать максимальный объем принимаемых данных. Но при возможности проверю, спасибо.
2. Проверял, не помогает. Адрес и порт один и тот же.
3. Не могу, у меня в будущем ожидается 2 соединения.

[Alechek]

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

При IPHEAD=1 (чтобы узнать длину) и аппаратном управлении потоком в таком контроле максимального объема нет необходимости.

[Daniil]

При IPHEAD=1 (чтобы узнать длину) и аппаратном управлении потоком в таком контроле максимального объема нет необходимости.

Я понимаю, просто изначально концепция была такая. Может быть пошел в неверном направлении...
В любом случае - спасибо за идею

[smalcom]

Журнал модема мне пока недоступен, т.к. модем физически далеко.

не отладочный журнал. Журнал обмена с модемом, вы же последовательный порт используете? Вот журнал обмена через порт.

[butthead2]

спец

И это говорит человек который в этом топике не выдал ни одной фразы по теме. И даже не пытался понять в чем проблема.
Лучше уж помолчите и не уводите ТС в ненужную ему сторону

[smalcom]

фразы по теме

вы уже показали, что ваша тема отлична от темы ветки, потому ничего и не видно вам.

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

[butthead2]

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

Фейспалм
Даже стало интересно, какие же это у вас доказательства которые уличают во вранье документацию на модем и соответственно меня тоже. Ах да, меня еще и в попутно в балабольстве.
С вопросом по сокетам уже слились, так не откажите в удовольствии посмотреть хоть эти доказательства

пс. Или хотя бы доказательства склеивания пакетов. Не пользовательских данных на выходе а именно пакетов

Сообщение отредактировал butthead2 - Dec 2 2016, 19:09

[CADiLO]

Так - "мальчики-девочки" - срач прекращаем. Рассказываю. Нервы потратил, ответ получил.

Модем действительно в буфер принимает поток as-is. Он не клеит, а просто заполняет буфер тем что пришло от оператора.

Как пришло - так и получите. Представьте сквозной канал с FIFO - это оно и есть.

И если данные слепились - вопрос не к Симкому а к писателям RTOS.

СТЕК ЛИЦЕНЗИОННЫЙ !!! и Симком там менять ничего не может - как МТК написало, так и работает.

Дополнение:

На уровне ЕАТ есть точки входа в API от РРР и выше - кто хочет поменять алгоритм, может воспользоваться.
Хоть свой стек рисуйте.

[Alechek]

СТЕК ЛИЦЕНЗИОННЫЙ !!! и Симком там менять ничего не может - как МТК написало, так и работает.

Вот это новость! Мое мировоззрение опять меняется...
Правда, непонятно, причем здесь МТК? А как же SIM300-SIM900? Там тоже Медиатек подсобил?
Я так понимаю, стек у Симкома лицензионный и одинаков для всех их модулей. Не будут же они несколько лицензий покупать...
Так что вопрос все-таки к Симкому. В названии команды IPHEAD слово "пакет" присутствует.
Опять таки, AT+CIPSRIP Show Remote IP Address and Port When Received Data , что, для всех входящих пакетов, даже с разных адресов:портов одна очередь пользовательских данных?
Что-то тут недоговорено....

[smalcom]

Фейспалм

У вас проблема на нейронном уровне. Вероятно, что у вас в кармане даже фото жены имеется, чтобы не забыть. Хотя, судя по созданным темам - там фото родителей.
Учитывая сию печальную болезнь могу подытожить, что до того уровня где я бы слился вам ещё столько учиться, что врядли столько проживёте.

[Alechek]

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

smalcom, все уже давно поняли, что Вы самый знающий.
Только умный не станет так засорять тему. Остыньте.

Кстати, CADiLO, я правиьно понял, что если UDP пакеты от оператора пришли в нарушенном порядке, то так они кучей данных в этом нарушенном порядке и вывалятся?

[smalcom]

smalcom, все уже давно поняли, что Вы самый знающий.

я такого не говорил. видимо вы компаньоны или партнёры, или как там у вас это называется.

[ArtemKAD]

Вот это новость! Мое мировоззрение опять меняется...
Правда, непонятно, причем здесь МТК? А как же SIM300-SIM900? Там тоже Медиатек подсобил?

Это все оттого, что Вы историю компании SimCom не знаете. У них всегда были стеки сторонних производителей. На Sim100/300 от Motorola или точнее TTPCom. Собственно изначально модули стали результатом сотрудничества TTPCom, AD и Sim Technology.

[Alechek]

Не буду спорить, что не знаю всех подробностей.
Вот только по поим представлениям, АТ интерфейс - это пользовательская надстройка над ОС, на которой работает чипсет модуля. И встроенный в модуль PPP/TCP/IP/FTP/HTTP - тоже пользовательская надстройка. Пусть лицензированная.
Так причем здесь Медиатек с его ОС? Он писал AT интерфейс? В т.ч. и чисто Симкомовские команды?

Конечный вопрос стоит так: отличается ли внешнее поведение по работе с данными, пересылаемыми посредством встроенного TCPIP стека модулей SIM300-SIM900-SIM800 в части их разбиения-объединения?

Так как у нас транспорт поверх UDP писан из расчета, что передача будет идти пакетами. Если 2 раза вызвал +CIPSEND, значит и придет 2 пакета, пускай в другом порядке, но 2. И в обратку, если сервер послал 2 пакета, у меня возникнет 2 раза +IPD URC.
C SIM300-SIM900 все отлажено. Подвохи от 800-й серии постоянно жду....

[Baser]

В названии команды IPHEAD слово "пакет" присутствует.
Опять таки, AT+CIPSRIP Show Remote IP Address and Port When Received Data , что, для всех входящих пакетов, даже с разных адресов:портов одна очередь пользовательских данных?
Что-то тут недоговорено....

Естественно, для каждого соединения свой приемный буфер.
Но: UART -то один, поэтому если вы не удосужились применить ни одну из команд
AT+CIPHEAD=1
AT+CIPSRIP=1
то, при наличии нескольких соединений и автоматической выдаче данных в порт,
пришедшие с разных соединений данные будут вываливаться поочередно в этот порт, и у вас не будет возможности их различить.
А если заголовки включены, то каждая порция данных из отдельного соединения будет иметь свой заголовок включая длину данных.

Вообще, хоть документация не сильно подробная, но она все же есть, и в ней достаточно информации.
Посмотрите например: SIM800 Series_TCPIP_Application Note

я правиьно понял, что если UDP пакеты от оператора пришли в нарушенном порядке, то так они кучей данных в этом нарушенном порядке и вывалятся?

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

И в обратку, если сервер послал 2 пакета, у меня возникнет 2 раза +IPD URC.

А вот на это точно не нужно рассчитывать.
Тем более, что вопрос топикстартера как раз и описывал ситуацию, когда +IPD URC одно на несколько пришедших почти одновременно пакетов.

[Alechek]

А вот на это точно не нужно рассчитывать.
Тем более, что вопрос топикстартера как раз и описывал ситуацию, когда +IPD URC одно на несколько пришедших почти одновременно пакетов.

Во-первых, все расчитывалось во времена SIM300. Там работало.
Во вторых, пока что все вилами на воде. И китайцы могли не так понять Эдуарда, и он их... Так как после его ответа все равно остались вопросы.

Естественно, для каждого соединения свой приемный буфер.

Ага, щаз.
Расширенный UDP режим, +CIPUDPMODE=1. Какое соединение?
К нам летят пакеты с разных адрсов. Сколько буферов?

[Baser]

Расширенный UDP режим, +CIPUDPMODE=1. Какое соединение?
К нам летят пакеты с разных адрсов. Сколько буферов?

С этим режимом не работал, определенно сказать ничего не могу

Для TCP вроде все однозначно, а для режима расширенного UDP непонятно для чего дополнительно есть мультиконект на 5 соединений.
Если и при одном соединении можно динамически переключать адрес кому посылать и принимать от любого.

Но это, как я понимаю, к изначальному вопросу ТС отношение не имеет, это уже новая постановка вопроса

[Alechek]

Для TCP вроде все однозначно, а для режима расширенного UDP непонятно для чего дополнительно есть мультиконект на 5 соединений.
Но это, как я понимаю, к изначальному вопросу ТС отношение не имеет, это уже новая постановка вопроса

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

Расширенный UDP - это как слушающий UDP сервер.

[butthead2]

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

Иного и не ожидал. Очередной поток словоблудия.
Поздравляю с почетным титутулом Самого Знающего Болтуна

[aiwa]

Дополнение:
На уровне ЕАТ есть точки входа в API от РРР и выше - кто хочет поменять алгоритм, может воспользоваться.
Хоть свой стек рисуйте.

А где про это можно почитать? В прилагаемой к ЕАТ документации - только raw-сокеты с IPPROTO.

[Velund]

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

Модемы Телит давно уже умеют работать с UDP и как надо, а не только как симком. Давно уже как умеют, с 185 прошивки у GL868 ЕМНИП. Правда нам с уважаемым коллегой из Атомы, присутствующим здесь на форуме, пришлось немного телитовской кровушки попить и мозгов их програмистстких повыносить.

PS: Впрочим как симком клеить датаграммы они тоже еще умеют - для совместимости с уже разработанными приложениями. Надо просто при открытии сокета шепнуть модему на ушко, что от него ждут - именно датаграмм, или потока. По дефолту будет поток, без разделения на датаграммы.

[butthead2]

пришлось немного телитовской кровушки попить и мозгов их програмистстких повыносить

"Не приставай к царю!" (с)
Главное что они прислушиваются, а потом тихонько делают.

По дефолту будет поток, без разделения на датаграммы.

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

[smalcom]

С момента последнего сообщения ТСа
https://electronix.ru/forum/index.php?showt...t&p=1465804
прошло 27 дней. В преддверии праздника хотелось бы услышать как он решил проблему со склеивающимися UDP-пакетами.

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

Надо просто при открытии сокета шепнуть модему на ушко, что от него ждут - именно датаграмм, или потока.

Простите, а разве не именно этим и отличаются UDP и TCP? Не знаю, как там у Телита, а у Симкома они открываются разными командами. Или Телиту кроме "масло" надо еще отдельно говорить "масляное"?

[molecul]

Простите, а разве не именно этим и отличаются UDP и TCP? Не знаю, как там у Телита, а у Симкома они открываются разными командами. Или Телиту кроме "масло" надо еще отдельно говорить "масляное"?

Уважаемый Velund имел в виду, что по умолчанию датаграммы идут потоком, и отделить что откуда пришло (если источников много) весьма проблематично. Telit же по его настоятельной просьбе (и к радости некоторых других потребителей) сделал возможность показывать подробную информацию об источнике:

Data view with UDP datagram informations:
SRING: <sourceIP>,<sourcePort><connId>,<recData>,
<dataLeft>,<data> same as before with <sourceIP>,<sourcePort> and
<dataLeft> that means the number of bytes left in the UDP datagram