Склеиваются 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 (чтобы узнать длину) и аппаратном управлении потоком в таком контроле максимального объема нет необходимости.

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