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

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

Спасибо.

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

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

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

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

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



В смысле?

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

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

Сообщение отредактировал meister - Aug 18 2009, 14:06

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

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

Сообщение отредактировал alx125 - Aug 18 2009, 23:03

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

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



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

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

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

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

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

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

Сообщение отредактировал =F8= - Aug 19 2009, 12:08

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





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