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


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


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

спец

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


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


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

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

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

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

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

ведь для

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

--------

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

2 Alechek



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнение:

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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



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

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

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

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

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

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

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

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

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

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

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


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

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

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

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