После установки UDP соединения

открывается сокет и я обмениваюсь данными. Как определить состояние, когда нужно будет установить соединение заново или даже перезапустить GPRS сессию?

Спасибо.

послать ченить и не получить ответа...

Это не вариант, нужно уметь посылать "в пустоту", в том смысле, что если "сервер" не отвечает - это совсем не значит, что надо заново открывать сокет или перезапустить GPRS.

как ты себе это представляеш?

а ну с терминалки какойнить пример приведи?

UDP пакет можно послать на несуществующий адрес. Это не TCP. Если такого адреса сейчас нет это не означает, что нужно перезапускать сокет модема или GPRS.



В смысле?

Никак, на то оно и UDP. Либо положить поверх UDP свой протокол.

А если я его открою в режиме TCP, как определить? Может, я как-то непонятно объснил. Есть устройство, оно периодически что-то шлет на сервер. БС может перезагрузиться, связь может ухудшиться так, что сокет нужно будет открыть заново. Это никак нельзя поймать?

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

Дело в том, что особенность UDP как раз в том и есть, что сетевое соединение не устанавливается. Т.е вы "пуляете" по адресу и все! В этом его фундаментальное отличие от TCP. Если же нужно контролировать сам факт доставки (что в принципе эквивалентно контролю соединения), то это надо делать вашим ПО (как бы реализация нового уровня стека протоколов над UDP/IP).

Как вариант периодически опрашивать DNS сервер, который был получен от при установлении соединения от оператора.

Я уж не знаю насколько аналогия близкая: шлем ethernet пакеты (да, прямо их), для их посылки нужно просто записать MAC-адрес получателя, есть получатель или нету - без разницы (может, он включится завтра). Мне надо поймать факт того, что выдернули кабель из розетки. Вы предлагаете делать это протоколом? В случае ethernet я могу у PHY спросить, чего там с кабелем-скоростью-дуплексом. Мне надо тоже самое для GPRS.



Мне вот это очень не нравится. Мне надо будет "периодически" закрывать соединение и получать адрес google.com (или любой другой). Если google.com недоступен (по разным причинам) делать вывод, что во всем виновато GPRS соединение и его надо перезапустить.

Закрывать соединение как раз не надо. GC864 до 6 соединений. Посылаете +++ переходите в командный режим делаете что нужно и снова возвращаетесь с своему соединению.

А мое имхо такое.
UDP годится для чатов и не более.. а в M2M и Embedded нужно более надежные каналы использовать... минимум TCP + свой контроль...

Ну потоковое ченить тоже гнать по UDP можно.. но по ТСП рулить в соседнем порту...

А физический уровень внутреннего стека ИМХО недоступен.
поднимайте внешний стек.. хотя, что это даст. Вопрос..
UDP сокет контролировать невозможно... жпрс можно.. а сокет - нет.
ИМХО

Если свой протокол поверх ложить то лучше как-раз UDP. Во-первых меньше лишних байтов по сети гоняется, во-вторых проще контролировать состояние соединения. ИМХО.

Чет вы не въехали. При чем тут google.com?
Вы должны слать запрос на DNS сервак который вам сообщает APN вашего провайдера.
Если уж этот сервак не работает то у вас вообще ничего не работает. Сессию точно надо рвать.
Тестить DNS можете любой служебной командой, например A для all
Протокол общения с DNS идет как раз по UDP, значит и работу своего сокета узнаете.





Ну эт вы от незнания наверно.
Во первых провайдерские NAT-ы пробиваются теми же STUN-ами только по UDP, а по TCP пробить NAT можно только тунелированием.
Но TCP тунелирование тоже не все NAT-ы пропускают.
С другой стороны ошибочно думать, что TCP самый лучший из протоколов для надежной доставки.
Есть куча протоколов с надежной доставкой работающих поверх UDP. Тот же L2TP

Лишние байты никуда не деваются... что по UDP нужно контролировать целостность доставленых пакетов (отвечая как минимум что получен и контролная сумма сошлась.
что по тсп тунелю это происходит на полу автомате )) лично я отвечаю приложением и на ТСП пакеты... да и вариантов ответа несколько. да и удаленное управление автоматом.

ладно это все вилами по воде )) да и задачи у всех разные.

Если я правильно Вас понял, нужно попытаться узнать IP адрес internet.mts.ru (для MTS)? Если неправильно - поправьте пожалуйста.

Стал смотреть про SD и QDNS, чтобы с ними работать нужно ипользовать набор команд "Easy GPRS", там сокеты настраиваются командой SCFG.

Это проходит:


Вот это:


возвращает "ERROR". Набор команд с одним соединением работает (SKTD).

Я сейчас качал Telit_AT_Commands_Reference_Guide_r6.pdf - там есть команда #SLUDP (Socket Listen UDP), которой раньше не было в описании. Может, у меня модем какой гнилой, что не поддерживает multisocket AT commands

я с 863 работал...
Я просто работал по протоколу TCP/IP, после AT#GPRS=1 далее коннектился к секету,посылал пачку данных на сервак.., но у меня сервак всегда отключался после выдачи мне ответа, поэтому каждый раз необходимо было снова коннектится к секету.
НО, перед тем как подключится к секету, я делал запрос AT#GPRS, если 1, то я в сети, если 0, то приходилось переактивировать GPRS соединение.