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

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

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

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

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

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

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

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

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

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

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

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

Модем действительно в буфер принимает поток 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 сервер.