GPRS and RealTime, возможно ли Опции

[GP_]

В трех словах. Есть трекер с СИМ300С внутри. Использую внутренний стек. Возникла задача реалтайма (под реалтаймом понимается задержка<20c), но не получается из-за частых разрывов соединения после которых не всегда быстро поднимается новое. Может подняться за 10с, а может за многа минут. Вопрос к уважаемому сообществу следующий. Возможен ли реалтайм (ну или почти реалтайм) вообще и на СИМ300 в частности?

[MicronSys]

для движующхся объектов GPRS -realtime -- нет
используйте CSD соединение

[AlexandrY]

В принципе возможно.
На SIM300, но не используя их внутреннего стека.
Точнее даже не пытался его использовать и ничего сказать не могу.

Недавно запустили систему где GPRS заменил ближнюю радиосвязь.
Т.е. объекты практически в прямой видимости у оператора, но при этом появилась возможность администрировать систему хоть из африки.
Объектов более 30. Каждый дивайс может управлять каждым, а также всеми может управлять оператор и удаленный администратор.
Среднее время реакции на комманду с подтверждением по TCP/IP - 1 сек. В 3G сети - 0.5 сек
Среднее время подсоединения к серверу из теплого состояния (оператор найден, но не установлен GPRS коннект) - 30 сек.
Хотя обычный режим все время быть на связи.
Разрывы связи наблюдаются, но они довольно разнообразные.
Чаще всего происходит задержка ответа, несколько десятков раз в сутки задержка достигает 10 и более сек.
На уровне TCP протокола больше разных сбоев и нюансов, но они не видны юзеру. Решаются подстройкой TCP стека.
Чтобы конкретно пропадала связь фиксируется один раз за несколько суток.

В трех словах. Есть трекер с СИМ300С внутри. Использую внутренний стек. Возникла задача реалтайма (под реалтаймом понимается задержка<20c), но не получается из-за частых разрывов соединения после которых не всегда быстро поднимается новое. Может подняться за 10с, а может за многа минут. Вопрос к уважаемому сообществу следующий. Возможен ли реалтайм (ну или почти реалтайм) вообще и на СИМ300 в частности?

[etoja]

В принципе возможно.

Нет, невозможно. По стандарту GPRS соединение может быть предоставлено с задержкой до 30 секунд с момента запроса на GPRS соединение по команде ATD*99***1#

[AlexandrY]

А я выходил по команде ATD*99#
Соединение вообще-то один раз организуется в начале работы.
А потом постоянно поддерживается.
Да и вообще соединение слишком часто делать невыгодно, поскольку за каждое соединение у нас к примеру берут определенную плату, как за SMS приблизительно.
Да и 30 сек нельзя считать не реальным временем.
Есть знаете ли такие сферы деятельности человека где 30 сек вполне реальное время.
Например, если в конфе отвечают спустя минуту после вопроса то я это считаю реальным временем

Нет, невозможно. По стандарту GPRS соединение может быть предоставлено с задержкой до 30 секунд с момента запроса на GPRS соединение по команде ATD*99***1#

[etoja]

GP явно написал:
"под реалтаймом понимается задержка<20c"

[PIC_Embedder]

Меня удивляет топикстартер. Здесь уже не раз хвастались, что сделали контроль перемещения автомобиля, с отображением на карте в реальном времени. Связь разумеется через GPRS. Никому не верим?

[GP_]

Делаю вывод: со своим стеком и СИМ300 можно сделать систему приближенную к реалтайм. Интересно по поводу встроенных стеков других модемов та же история? Вообще-то мне кажется странным приговор типа "кривой стек". TCP/IP стек штука не новая и давно уже откатанная и тот же СИМКОМ наверняка использует стандартные решения. Почему стек который зашит в их АРМ работает хуже стека зашитого в мой, например, АРМ. Предполагаю, есть принципиальное отличие на уровне GPRS (формулировка мне не нравится, но лучше не придумал).

[Baser]

Делаю вывод: со своим стеком и СИМ300 можно сделать систему приближенную к реалтайм...

Не нужно зацикливаться на стеке и ставить его во главу угла. "Кривой" стек или "ровный", все равно он даст только малую толику от того "реалтайма". При нормальных условиях время передачи данных составляет 1-3 секунды независимо от стека.

Основной вопрос "реалтайма" это вероятность наличия нормальных условий.
А эта вероятность зависит, в основном, от внешних факторов:
- качества покрытия данной местности ГСМ сетью;
- загрузкой этой сети в данное время;
- загрузкой интернет-сегмента канала передачи данных;
- загрузкой оконечного сервера;
- можно еще чего-нибудь придумать

Так что основной вывод: технология GPRS позволяет передавать данные в реальном времени.
Но с вероятностью в ХХ%
И есть вероятность (довольно большая), что ХХ% будут равны нулю
И вы повлиять на неё никак не сможете...

[AlexandrY]

Тайминги типичного процесса c внешним стеком.

40 сек - ожидание регистрации в сети GSM.
2 сек - инициализация модема разными командами, проверка качества сигнала
36 мсек - от команды AT*99# до ответа CONNECT
5 сек - от сообщения CONNECT до завершения выполнения всех этапов PPP подключения
1 сек - установка TCP коннекта с сервером
1 сек - посылка сообщения по TCP и приход ответа

У встроенного стека нет явного этапа PPP поэтому может у них даже быстрее будет.
Вот интересно, кто нибудь скажет?

GP явно написал:
"под реалтаймом понимается задержка<20c"

[Baser]

Тайминги типичного процесса c внешним стеком.
...
У встроенного стека нет явного этапа PPP поэтому может у них даже быстрее будет.
Вот интересно, кто нибудь скажет?

Я могу сказать, только это никакой практической ценности не имеет, по причинам, описанным мною выше.
Эти тайминги гуляют очень сильно от случаю к случаю.
Да и статистики у меня нет. Вот взял парочку сохранившихся логов.

Итак: SIM300Z B15, встроенный стек, TCP connect. Тайминги перечисляю из разных логов.

1. Регистрация в сети (от RDY до Call Ready) - 19; 4; 10; 19 sec
2. Подключение к GPRS (AT+CGATT=1) - 9; 9; 8; 10 sec
3. TCP connect с сервером - 7; 37; 7; 7 sec
4. Посылка данных и получения ответа от сервера - 2; 2; 21; 5; (типовое 1-3) sec

Но времена подключения могут еще сильно зависить от тарифного плана оператора, от бонусов.
Вот моя карта, которая много лет уже в работе (лояльный старый клиент) подключается очень быстро.
А новые, купленные только что, карты могут подключаться по минуте...

Так шта...

[ivstech]

2. Подключение к GPRS (AT+CGATT=1) - 9; 9; 8; 10 sec

Когда GPRS был недоступен (определял по индикации своего сотового телефона), SIM508 на команду AT+CGATT не отвечал и в течение 5 минут, дальше я не ждал и его перезапускал. Потом эту команду я убрал, сразу делаю AT+CIPSTART

[GP_]

Пример статистики по соединениям за небольшой отрезок времени в файле. Это обработанный лог сервера для двух приборов. Надо добавить, что это ближе к худшему варианту. Обычно картинка лучше, а такая наблюдается в районе 9 часов и 16 часов, по всей видимости пик загрузки сетей. Оператор MTC Украина.

Прикрепленные файлы

 __________.pdf ( 29.51 килобайт ) Кол-во скачиваний: 97

 

[Baser]

Пример статистики...

У вас приборы с модемами на подвижных объектах или стационарные?
У меня в лабораторных условиях в городе пропадения связи никогда не наблюдалось.
На подвижных объектах - да, теряется...

[etoja]

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

Если в лаборатории всё работает, значит вы чего-то не заметили.

[GP_]

На подвижных. Но на стационарных тоже достаточно часто рвется. Разрыв TCP соединения необязательно связан с пропаданием связи, я так понимаю.

[M_Z]

На подвижных. Но на стационарных тоже достаточно часто рвется. Разрыв TCP соединения необязательно связан с пропаданием связи, я так понимаю.

Да конечно.
Это может быть к примеру плохое питание модуля. При резком увеличении потребления в момент перехода модуля в режим передачи, просадка питания, т.д.
Нельзя исключать и программные проблемы.

[Harbinger]

Нельзя исключать и программные проблемы.

В т.ч. со стороны оператора.

[Baser]

Если в лаборатории всё работает, значит вы чего-то не заметили.

Дык, это один из законов Мерфи, кто спорит, что багов там полно. Да и по целым суткам в лаборатории тоже не включал...

Из саги "This is how things work in Information Technology"

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

На подвижных. Но на стационарных тоже достаточно часто рвется. Разрыв TCP соединения необязательно связан с пропаданием связи, я так понимаю.

У вас оператор, случайно, принудительно не рвет соединение, если по нему больше ХХ минут не передавались данные?
В наших краях такое было до недавнего времени, сейчас, правда, оевропеились, больше не рвут.
Для гарантии я каждые 2 мин шлю короткий пакет на сервер, несколько байт (если не нужно данные передавать).

[GP_]

При передаче с интервалом 20с и 2мин разницы в интенсивности разрывов "на глаз" не видно. Очень интересно было бы глянуть на чью-то подобную статистику (соединение в открытом состоянии)/(соединение в закрытом состоянии) для внутреннего стека СИМ300х.

[M_Z]

А что значит ?

(соединение в открытом состоянии)/(соединение в закрытом состоянии)

Если речь идет о разрыве соединения, то я не понимаю (соединение в закрытом состоянии). Оно и так уже закрыто

Сообщение отредактировал M_Z - Mar 4 2009, 13:19

[etoja]

GPRS соединение - это захват свободных в данный момент голосовых каналов.
Поэтому в GPRS:
1) нет оплаты за время
2) скорость обмена меняется до полного замирания.

[GP_]

(соединение в открытом состоянии) - это когда на AT+CIPSTATUS отвечает CONNECT OK
(соединение в закрытом состоянии) - это когда на AT+CIPSTATUS отвечает что-нибудь другое
при этом ваш автомат должен пытаться соединение поднять если оно упало

Сообщение отредактировал GP_ - Mar 4 2009, 14:09

[M_Z]

(соединение в открытом состоянии) - это когда на AT+CIPSTATUS отвечает CONNECT OK
(соединение в закрытом состоянии) - это когда на AT+CIPSTATUS отвечает что-нибудь другое
при этом ваш автомат должен пытаться соединение поднять если оно упало

Ну эт понятно.
Но тогда непонятен вопрос о статистике разрывов соединения в случае когда соединение разорвано
А вобще то реально мы тестили неоднократно время от события и до появления этого события на сервере. В основном это в не более 15сек. Хотя бывают довольно редкие но достигающие 1мин. Но это скорее была проблема связи и модем по новой регистрился в сети со всеми последующими настройками модема

Сообщение отредактировал M_Z - Mar 4 2009, 14:48

[AlexandrY]

Ну.., у вас совсем запущенный случай.
Просите оператора сделать вам VPN.
VPN освобождает от проблемы дефицита публичных IP.
Понятно также что у каждого APN есть свой пул публичных IP определенного размера.
Эти размеры определяют средние времена простоя в ожидании доступа к открытому интернету. Поиграйтесь с APN.

Потом объясните что в вашем понимании разрыв связи.
Отключение контекста PDP?
Или молчание модема в ответ на ваши запросы по TCP.
А UDP там у вас можно посылать? А ICMP запросы?
Что отвечает на пинги APN?

А пробовали сделать маршрут RIP-ом?
Проблема потери маршрута в роутерах реальная проблема.
GGSN то не бездонная база маршрутов.
Если вы на границе RA то все время меняется маршрут пакетов из-за чего пакеты просто теряются, а PDP контекст при этом сохраняется.
Поставте направленные антены.

Стек TCP должен быть перенастроен на подходящий KEEPALIVE. Подрегулировано время ретрансмитов и их количество.

Пример статистики по соединениям за небольшой отрезок времени в файле. Это обработанный лог сервера для двух приборов. Надо добавить, что это ближе к худшему варианту. Обычно картинка лучше, а такая наблюдается в районе 9 часов и 16 часов, по всей видимости пик загрузки сетей. Оператор MTC Украина.

[M_Z]

Поставте направленные антены.

Это очень хороший совет
Трекер это устройство подвижное. Либо человек носит его в кармане, либо на каком то автомобиле установлено. На автомобиле то еще можно представить направленную антенну, правда непонятно куда ее повернуть? А вот человек с направленной антеной это очень интересно
Да и улучшение ситуации от направленной антенны незначительное.

Мне кажется очень хорошо ответил Baser Вчера, 19:30

Там все очень даже конкретно и понятно описано.

Сообщение отредактировал M_Z - Mar 4 2009, 17:26

[AlexandrY]

GSM - это радиосвязь.
Когда надо дозвониться все носятся по офису в поисках подходящего места.
А как GPRS так забываем что ему тоже хорошая радиовидимость нужна.
Подумайте что легче: поставить на человека антену или приблизить базовую станцию.

Baser конечно умную вещь сказал, кто спорит.
Но в жизни все таки интереснее числа.
Но никто наверно не будет спорить, что суммарное время наличия связи превышает 90% в зонах где оператор ее гарантирует или не так?
Так это отличный показатель чтобы поддерживать связь в реальном времени.

Это очень хороший совет
Трекер это устройство подвижное. Либо человек носит его в кармане, либо на каком то автомобиле установлено. На автомобиле то еще можно представить направленную антенну, правда непонятно куда ее повернуть? А вот человек с направленной антеной это очень интересно
Да и улучшение ситуации от направленной антенны незначительное.

Мне кажется очень хорошо ответил Baser Вчера, 19:30

Там все очень даже конкретно и понятно описано.

[M_Z]

GSM - это радиосвязь.
Когда надо дозвониться все носятся по офису в поисках подходящего места.
А как GPRS так забываем что ему тоже хорошая радиовидимость нужна.
Подумайте что легче: поставить на человека антену или приблизить базовую станцию.

Baser конечно умную вещь сказал, кто спорит.
Но в жизни все таки интереснее числа.
Но никто наверно не будет спорить, что суммарное время наличия связи превышает 90% в зонах где оператор ее гарантирует или не так?
Так это отличный показатель чтобы поддерживать связь в реальном времени.

Мне кажется самая ценная информация оз этого поста

GSM - это радиосвязь.

Я считал что GSM, передача информации по проводам.

Все остальное это утверждение что 2*2=4.

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

Сообщение отредактировал M_Z - Mar 4 2009, 18:49

[AlexandrY]

Считать лучше надо.
У нас со следующего года вводят 3G с MIMO на 20 Mbps.
Вот где потеха с антенами будет.
Пешеходы наверно на ушах антены вешать будут, скорости то хочется.

Я считал что GSM, передача информации по проводам.

[GP_]

"Но в жизни все таки интереснее числа."

Хотелось бы именно числа увидеть, ну типа, "я использую внутренний стек, в течение суток соединение разорвалось 7 раз, переустанавливается за 5с мин 40с макс", чтобы было с чем сравнить. Сравнивать с "у нас все класно работает" тяжело.
"Потом объясните что в вашем понимании разрыв связи."
Со стороны сервера выглядит так: TcpServer::accept_new_connections - принял соединение, TcpServer::close_connect() - отвалился
Разрыв связи - промежуток времени от close_connect до accept_new_connections.
В любом случае, спасибо за участие

[AlexandrY]

А вот это не разговор.
Что такое TcpServer ? В какой среде написан?
TcpServer::close_connect() - это что, процедура вызываемая вами, хендлер ивента, сам обработчик ивента?
Windows сокеты могут держать соединение многие годы после того как связь с объектом пропала, т.е. серверу в вопросе связи меньше всего доверять можно.
Смотрите логи снифера, а не сервера.

Со стороны сервера выглядит так: TcpServer::accept_new_connections - принял соединение, TcpServer::close_connect() - отвалился
Разрыв связи - промежуток времени от close_connect до accept_new_connections.

[M_Z]

А вот это не разговор.
Что такое TcpServer ? В какой среде написан?
TcpServer::close_connect() - это что, процедура вызываемая вами, хендлер ивента, сам обработчик ивента?
Windows сокеты могут держать соединение многие годы после того как связь с объектом пропала, т.е. серверу в вопросе связи меньше всего доверять можно.
Смотрите логи снифера, а не сервера.

Вот именно!
Или вполне информативным является лог сервера, но сравнивать нужно разницу времен события(время события указанное в сообщении), и время серверное в которое было принято сообщение. Таким образом можно получить времена задержек, что является главным параметром передачи информации в реальном времени. И вобщем то не столь важно был разрыв соединение и его востановили или сообщение передавалось минуту(такое тож бывает. Соединение не разрывалось а сообщение передается десятки секунд).

[etoja]

Разрыв соединения - это отсутствие от сервера TCP-пакетов подтверждения (ACK) на TCP-пакеты запросов клиента в течении заданного интервала времени,
либо обмен пакетами по временной диаграмме "соединение закрыто".

Для AlexandrY. Вы пишете: "Windows сокеты могут держать соединение многие годы после того как связь с объектом пропала"
Это не так. При обмене по протоколу TCP используется специальный Keep Alive таймер для периодического обмена пакетами с целью обнаружения активности клиента и сервера. По этому таймеру соединение будет закрыто.

[M_Z]

Разрыв соединения - это отсутствие от сервера TCP-пакетов подтверждения (ACK) на TCP-пакеты запросов клиента в течении заданного интервала времени,
либо обмен пакетами по временной диаграмме "соединение закрыто".

Для AlexandrY. Вы пишете: "Windows сокеты могут держать соединение многие годы после того как связь с объектом пропала"
Это не так. При обмене по протоколу TCP используется специальный Keep Alive таймер для периодического обмена пакетами с целью обнаружения активности клиента и сервера. По этому таймеру соединение будет закрыто.

Мы сталкивались ситуацией, когда GSM модем попросту выключить питание при активном конекте, то то на сервере соединение якобы оставалось активным.
Если модем выключать корректно, то тогда все окей. Сервер тудже понимает что соединение разорвано.
Так что на практике ситуация когда сервер якобы держит соединение с GSM модулем, который давно уже выключен абсолютно реальна.

[GP_]

А вот это не разговор.

Отставить распихивать огурцы по дырам
"Поставте направленные антены."
Тогда "объясните что в вашем понимании""направленные антены"
Антенны, которые стоят на базовых станциях, относятся к направленным? Или антенны РЛС? Или может вы будете возражать против утверждения, что любая антенна с ненулевой электрической длиной будет направленной? Или вы хотели сказать более эффективные антенны?
По сути.
Я не являюсь разработчиком серверного программного обеспечения. В программный комплекс входит программа, которая установлена под win nt, и, собственно, обрабатывает входящие TCP соединения. Она формирует несколько логов. В одном из логов фиксируются различные события. Я выбрал события с заголовком TcpServer. Предполагаю что событие accept_new_connections означает both the client and server have received an acknowledgment of the connection.
2009-03-06 01:14:56:187 TcpServer::accept_new_connections() new connection 192.168.5.1:53418 connects.size()=2
С закрытием сложнее.
2009-03-06 00:45:18:031 GsmIpDevice::do_read_connection() 192.168.5.1:61195: Socket was closed
2009-03-06 00:45:18:031 TcpServer::close_connect() 192.168.5.1:61195
Или
2009-03-06 01:19:47:015 TcpServer::validate() connection 192.168.5.1:61763 expired (прим., встречается редко)
Во втором случае, думаю, сервер закрывает. В первом даже затрудняюсь сказать, кто закрываает.

Сообщение отредактировал GP_ - Mar 6 2009, 09:05

[etoja]

Мы сталкивались ситуацией, когда GSM модем попросту выключить питание при активном конекте, то то на сервере соединение якобы оставалось активным.
Если модем выключать корректно, то тогда все окей. Сервер тудже понимает что соединение разорвано.
Так что на практике ситуация когда сервер якобы держит соединение с GSM модулем, который давно уже выключен абсолютно реальна.

Соединение должно быть закрыто сервером при молчании клиента более 20 минут. Пользуйтесь UNIX сервером, вместо Windows и всё будет правильно.

[Rst7]

Соединение должно быть закрыто сервером при молчании клиента более 20 минут.

Да ну? Откуда такое требование? Не говоря уже о том, что RFC1122 говорит о двухчасовом периоде Keep-Alive по дефолту.

Другое дело, что 2 часа - весьма занадто для GPRS. Так что лучше выбрать время поменьше. Правда, под виндой это время устанавливается единоразово ключем в реестре. Так что для портабельности лучше делать собственный Keep-Alive в виде маленького пакетика данных, посылаемого с нужным периодом.

[AlexandrY]

Пока видно, что дивайсы используют адреса из подсети с диапазоном всего в 254 адреса.
Поскольку сервер сообщает о закрытии сокета значит либо он явно получает команду о закрыти либо сам инициирует закрытие.
Контроль Keep Alive проходит гораздо реже, раз в 2-а часа где-то по умолчанию.
Т.е. ваши разрывы никак не связаны с фиксацией самими сокетами долгого отсутствия связи.

Еще раз советую поставить снифер на компе сервера и смотреть его лог.
Ну а лучше и безопасней делать внешний TCP стек в дивайсах. Будет гораздо проще отлаживать такие проблемы.

2009-03-06 01:14:56:187 TcpServer::accept_new_connections() new connection 192.168.5.1:53418 connects.size()=2
С закрытием сложнее.
2009-03-06 00:45:18:031 GsmIpDevice::do_read_connection() 192.168.5.1:61195: Socket was closed
2009-03-06 00:45:18:031 TcpServer::close_connect() 192.168.5.1:61195
Или
2009-03-06 01:19:47:015 TcpServer::validate() connection 192.168.5.1:61763 expired (прим., встречается редко)
Во втором случае, думаю, сервер закрывает. В первом даже затрудняюсь сказать, кто закрываает.

И это еще не значит что сокет закроется.
В либах Indy сокеты ничего не сообщат даже через 2-а часа молчания. Там просто нет такого ивента.
И кстати приводят довольно убедительное обоснование такой философии.
В частности утверждая что это (в смысле управление тайм-аутами подключений) должно определяться характером приложения и очень индивидуально.

Да ну? Откуда такое требование? Не говоря уже о том, что RFC1122 говорит о двухчасовом периоде Keep-Alive по дефолту.

Другое дело, что 2 часа - весьма занадто для GPRS. Так что лучше выбрать время поменьше. Правда, под виндой это время устанавливается единоразово ключем в реестре. Так что для портабельности лучше делать собственный Keep-Alive в виде маленького пакетика данных, посылаемого с нужным периодом.

[Rst7]

И это еще не значит что сокет закроется.
В либах Indy сокеты ничего не сообщат даже через 2-а часа молчания. Там просто нет такого ивента.

Да пусть авторы Делфи вместе со своими компонентами с разбегу об стену убъются

Есть вменяемый интерфейс для сокетов - bsd. А поделки Борланда - это от лукавого.

В частности утверждая что это (в смысле управление тайм-аутами подключений) должно определяться характером приложения и очень индивидуально.

А это как раз вполне логично. Ганц логиш по фашистски