Пишу клиент-сервер, столкнулся с проблемой на gprs. В некоторый момент времени пакеты перестают приходить на сервер. По таймауту сервер даже закрывает соединение через 15 минут, а через gprs команды все посылаются и посылаются как будто ничего не произошло. Использую TCP.

Вопрос собственно в том, может ли такое вообще быть или у меня в голове проблемы?

Спасибо.

Здравствуйте, Аноним, Вы писали:

А>Пишу клиент-сервер, столкнулся с проблемой на gprs. В некоторый момент времени пакеты перестают приходить на сервер. По таймауту сервер даже закрывает соединение через 15 минут, а через gprs команды все посылаются и посылаются как будто ничего не произошло. Использую TCP.

А>Вопрос собственно в том, может ли такое вообще быть или у меня в голове проблемы?

А почему бы и нет. Сам TCP/IP не гарантирует доставку пакетов, так что они имею полное право терятся.

GIV>А почему бы и нет. Сам TCP/IP не гарантирует доставку пакетов, так что они имею полное право терятся.
IP — не гарантирует. TCP — гарантирует (по крайней мере Вам должно быть сообщено, если не удалось доставить)...

> Пишу клиент-сервер, столкнулся с проблемой на gprs. В некоторый момент
> времени пакеты перестают приходить на сервер. По таймауту сервер даже
> закрывает соединение через 15 минут, а через gprs команды все посылаются
> и посылаются как будто ничего не произошло. Использую TCP.


жпрс — как протокол более низкого уровня — доставку не гарантирует.
Гарантия доставки обеспечивается протоколом tcp.
Естественно, что где-то по пути соединение может оборваться, а
TCP-соединение будет и дальше считаться установленным.

Чтобы такого избежать — пользуйте keep-alive. Например, раз в минуту
отправлять пакетик и ждать на него ответа. Если через 20 секунд не
пришёл ответ на пакетик — соединение считать разорванным.

Но TCP гарантирует что отправитель узнает что доставка состоялась или не состоялась.

Далее предположения, я особо не в курсах.

Если TCP стек в модеме реализован корректно, то можно поинтересоваться таким параметром как максимальный размер неподтвержденных данных. Обычно ставится на уровне десятка килобайт, о нем договариваются высокие стороны в момент установления соединения. Может вы отправляете сотню байт, дык модем и не возражает — кидает себе в нутряной буфер и ждет подтверждений не дергаясь.

Здравствуйте, Аноним, Вы писали:

А>Пишу клиент-сервер, столкнулся с проблемой на gprs. В некоторый момент времени пакеты перестают приходить на сервер. По таймауту сервер даже закрывает соединение через 15 минут, а через gprs команды все посылаются и посылаются как будто ничего не произошло. Использую TCP.

А>Вопрос собственно в том, может ли такое вообще быть или у меня в голове проблемы?

Думаю, что вы все правильно делаете. Проблемы скорее всего даже не в GPRS,а в канале. Инет через GPRS имеет меньший приоритет чем голосовые данные, поэтому, если "голосовая" нагрузка в той же соте где и вы возрастает, то ваши данные остаются где-то, где ожидают передачи до тех пор пока голосовая нагрузка спадет. Если все это затягивается на долго, то сервер отваливает по таймауту, а вы, возможно, еще долго об этом просто знать не будете (канал занят).
Приблизительно так, если что, то меня поправят.

Ну тут к сожалению поля для маневра нет, такоих настроек модем не предлагает, то етсь эти параметры безусловно существуют, но простым смертным их сменить нельзя. Ситуация такова на GR47 и Sim300

В моих условиях это практически вдвое поднимает трафик Механизм реализован для 15 минут, но есть капризные клиенты, им и 15 минут терять жалко, выхода то я понимаю что нет

С забитым каналом проблем нет, стоит флешка на 7 часов записи, проблема именно в том, что по модему данные считаются отосланными, а на самом деле сервер их не получает. Непонятно где бага заложена, в TCP/IP модема или все же GSM сеть врет, наверное я этого никогда не узнаю

Здравствуйте, DDD123456, Вы писали:


DDD>Но TCP гарантирует что отправитель узнает что доставка состоялась или не состоялась.

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

DDD>Далее предположения, я особо не в курсах.
DDD>Если TCP стек в модеме реализован корректно, то можно поинтересоваться таким параметром как максимальный размер неподтвержденных данных. Обычно ставится на уровне десятка килобайт, о нем договариваются высокие стороны в момент установления соединения. Может вы отправляете сотню байт, дык модем и не возражает — кидает себе в нутряной буфер и ждет подтверждений не дергаясь.

Хм... у модема есть TCP стек? Или речь про IP? Обычно в случае GPRS он реализует только PPP, а IP — только payload этого PPP.

Есть, это промышленный GSM модем

Здравствуйте, Аноним, Вы писали:

А>Пишу клиент-сервер, столкнулся с проблемой на gprs. В некоторый момент времени пакеты перестают приходить на сервер. По таймауту сервер даже закрывает соединение через 15 минут, а через gprs команды все посылаются и посылаются как будто ничего не произошло. Использую TCP.

Я сталкивался с подобной проблемой. Для ее решения использовал "искусственное" подтверждение с сервера после приема определенного куска данных (т.к. контроль подтвержтения используемый TCP стеке модема недоступен для пользователя).
Можно использовать UDP и реализовать собственный протокол с подтверждением и таймаутами и на этом сэкономить трафик (к тому же заголовок UDP пакета меньше), но при этом возникают трудности с идентификацией уникальных логических соединений клиент-сервер (если интересно — могу поделится опытом использования UDP).

У меня была еще одна проблема при использовании GPRS в целом:
После того, как модем установит GPRS сессию (получит IP и т.д.), он передает данные на сервер и держит сессию открытой (опять же экономия — многие провайдеры округляют GPRS трафик в большую сторону при закрытии сессии — а нам этого не нужно ). Сессия может быть открыта долгое время (десятки часов), главное чтобы была какая-либо активность в пределах установленного провайдером таймаута (обычно 10-15 минут). Так вот, иногда происходит следующее: GPRS сессия продолжает быть активной (разрыва не происходит), а подключиться к серверу невозможно — ошибка подключения — сервер не отвечает (так как будто на удаленном сервере сервис не запущен). Короче все запросы уходят в никуда! И это продолжается до бесконечности, т.е. сеть перестает отвечать (хотя другие модемы в этой же соте продолжают исправно работать). Исправить это можно разрывом GPRS сессии и повторным подключением. А как узнать что перестала отвечать сеть или просто сервер не запущен? Приходится в случае, если к серверу подключиться неудается, посылать ICMP пакеты на какие-нибудь постоянно работающие сервера (например DNS серверы первого уровня), чтобы контролировать что модем еще "в сети".
Может это связано с оборудованием? Я использовал gsm-модемы Wavecom.
Может это особенноти работы GPRS? Я использовал не одного оператора — везде наблюдалась эта проблема.
Может есть предложения как контролировать "в сети ли я"?

Цепочка работы такая :

[Terminal] <---> [GPRS Gate] <----> [your IP]

Так, вот GPRS Gate это вообще какой-нибудь Линкусовый гейт (или Cisco железка), которая поднимает TCP соединение до вашего сервера и передаёт туда байты, принимает ответы. Так, вот во избежание "мёртвых" сессий и траты времени оборудования эпизодически сессии рубятся оператором (те самые 15-20 минут). Но, TCP соединение моджет упасть и само по себе, а вот его переподъём не предусмотрен. Вообще весь GPRS заточен под сессионую работу по 30-40 Кб. Так-что пытаться обмануть железяку не выйдет. Просто переподнимайте GPRS подключение.