Полная версия этой страницы:
CIPCLOSE быстро или медленно?
RadikX
Mar 26 2012, 09:30
Использовали в своих девайсах AT+CIPCLOSE без параметров и особо незаморачивались. Когда начали досконально изучать обмен с сервером по GPRS выяснилось что задержки между запросом и ответом могут достигать почти 20 сек, что катастрофично. Закрытие сокета может достигать аналогичной временной задержки. В мануале указаны два возможных способа закрытия соединения быстрый(AT+CIPCLOSE=1) и медленный (0-по умолчанию). Вопрос: чем плох быстрый способ закрытия соединения и какие проблемы может принести его применение?
Цитата(RadikX @ Mar 26 2012, 12:30)

Использовали в своих девайсах AT+CIPCLOSE без параметров и особо незаморачивались. Когда начали досконально изучать обмен с сервером по GPRS выяснилось что задержки между запросом и ответом могут достигать почти 20 сек, что катастрофично. Закрытие сокета может достигать аналогичной временной задержки. В мануале указаны два возможных способа закрытия соединения быстрый(AT+CIPCLOSE=1) и медленный (0-по умолчанию). Вопрос: чем плох быстрый способ закрытия соединения и какие проблемы может принести его применение?
а "at+cipshut" не пробовали?
я именно этой командой пользуюсь. проблем не замечал
RadikX
Mar 26 2012, 10:34
Неверное я неправильно сформулировал вопрос. Я имею ввиду команды отличаются только ответом: сразу в быстром и по факту в медленном. Или все же он реально его как-то обрывает и я его могу тут же использовать снова? Проверить на стенде сложно: ситуация происходит несколько раз в сутки.
"а "at+cipshut" не пробовали? "
AT+CIPSHUT, если не ошибаюсь, закрывает полностью GPRS сессию, что приводит к округлению трафика.
Aurochs
Mar 26 2012, 10:35
Цитата(RadikX @ Mar 26 2012, 12:30)

выяснилось что задержки между запросом и ответом могут достигать почти 20 сек, что катастрофично.
Вам повезло с провайдером. Мне приходилось наблюдать задержки до полутора минут.
И в чем катастрофа, если не секрет?
Цитата(RadikX @ Mar 26 2012, 12:30)

Вопрос: чем плох быстрый способ закрытия соединения и какие проблемы может принести его применение?
Насколько я понимаю, то в этом случае происходит односторонне закрытие подключения и для сервера провайдера и целевого сервера клиент просто исчезает в никуда.
RadikX
Mar 26 2012, 10:42
Цитата(Aurochs @ Mar 26 2012, 14:35)

Вам повезло с провайдером. Мне приходилось наблюдать задержки до полутора минут.
И в чем катастрофа, если не секрет?
Охренеть...
Приборы используются в охране. Все жестко.
Цитата(RadikX @ Mar 26 2012, 13:34)

AT+CIPSHUT, если не ошибаюсь, закрывает полностью GPRS сессию, что приводит к округлению трафика.
у нас на МТС побайтная тарификация. то есть округления нет.
по России, как мне утверждали у некотрых операторов округляют раз в сутки. просто важно выбрать правильно тарифный план и оператора.
а с "AT+CIPCLOSE" я тоже попробовал - не понравилось.
RadikX
Mar 26 2012, 13:32
Есть кто-нибудь знающий "физику" работы GPRS? Чем обусловлены эти задержки? Как их минимизировать? Возможно ли как-то повлиять на ситуация переотрытием сокета или GPRS соединения?
Чисто интуитивно, я думаю, это как-то связано с тем что GPRS в GSM вторичен по отношению к голосовому каналу.
rx3apf
Mar 26 2012, 13:52
Цитата(M_Z @ Mar 26 2012, 14:57)

у нас на МТС побайтная тарификация. то есть округления нет.
по России, как мне утверждали у некотрых операторов округляют раз в сутки. просто важно выбрать правильно тарифный план и оператора.
а с "AT+CIPCLOSE" я тоже попробовал - не понравилось.
А мне пришлось отказаться от +CIPSHUT в пользу +CIPCLOSE. Иначе регулярное использование +CIPSHUT провоцировало ситуацию, когда GPRS просто прекращал работать ("PDP DEACT" немедленно после +CIPSTART, причем продолжалось очень долго, и наблюдалось регулярно). Стал закрывать - стало работать многократно стабильнее.
Цитата(RadikX @ Mar 26 2012, 16:32)

Возможно ли как-то повлиять на ситуация переотрытием сокета или GPRS соединения?
Используйте UDP. Закрываться/открывыться будет мгновенно.
Цитата
а "at+cipshut" не пробовали?
Нафига полумеры? Лучше рубить по питанию.
Цитата(=F8= @ Mar 26 2012, 18:04)

Используйте UDP. Закрываться/открывыться будет мгновенно.
Нафига полумеры? Лучше рубить по питанию.
+1

На все 100% поддерживаю!
RadikX
Mar 27 2012, 03:28
Нашел документальные нормы задержек. Может кому будет интересно...
Нажмите для просмотра прикрепленного файлаНажмите для просмотра прикрепленного файлаSDU - Service Data Unit. Модули данных GPRS
Как видно задержки в 1.5 минуты это еще очень хорошо.
CADiLO
Mar 27 2012, 06:05
>>> Чисто интуитивно, я думаю, это как-то связано с тем что GPRS в GSM вторичен по отношению к голосовому каналу.
Абсолютно верно. И если сота будет перегружена голосовыми звонками, то все слоты отдадут под них.
Поэтому в охранные системы часто ставят карточки 2х операторов и пользуются резервным каналом.
RadikX
Mar 27 2012, 07:23
Цитата(CADiLO @ Mar 27 2012, 09:05)

Поэтому в охранные системы часто ставят карточки 2х операторов и пользуются резервным каналом.
Ну так то оно в принципе и сделано. Одна симка резервная. Однако иметь две АКТИВНЫЕ симки это накладно - надо иметь два модуля и оплачивать два соединения. А регистрация в сети, потом регистрация в GPRS - опять потери времени. Я думаю что решить программными средствами здесь не получится. GPRS в охране может использоваться только как вторичный канал, либо где 10 минут приемлемое время.
Кстати нашел вот такую команду: AT+CIPQRCLOSE, в которой как раз и можно настроить быстрое закрытие сокета: с одним или двойным подтверждением.
CADiLO
Mar 27 2012, 07:47
Не нужно две активных - я такое в единичных устройствах видел. Вполне хватает переключения.
>>>А регистрация в сети, потом регистрация в GPRS - опять потери времени.
Вы на время слишком не упирайте, потому как если сеть не даст слоты, то и две активных карточки не помогут.
Поэтому реальное время реакции на срабатывание вполне укладывается в 5-7 минут.
Ведь многие даже не держут модуль постоянно в активном режиме, а включают его только после срабатывания сигнализации или по времени чтобы сбросить данные.
andrewlekar
Mar 27 2012, 08:46
Вот у меня с закрытием проблем особых не было. Я использую во-первых CIPSHUT, а во-вторых в нормальных условиях не закрываю соединение. А вот с открытием сессии... То ли CSTT, то ли CIICR вешает модуль намертво на минуту где-то, при некоторых условиях. Не смертельно, но весьма неприятно.
_Артём_
Mar 27 2012, 10:57
Цитата(CADiLO @ Mar 27 2012, 10:47)

Поэтому реальное время реакции на срабатывание вполне укладывается в 5-7 минут.
Ничего себе время рекции.
Цитата(CADiLO @ Mar 27 2012, 10:47)

Ведь многие даже не держут модуль постоянно в активном режиме, а включают его только после срабатывания сигнализации или по времени чтобы сбросить данные.
Лучше с sleep-e держать. Или там GPRS-контент/сокет теряется?
CADiLO
Mar 27 2012, 11:27
Как я уже написал, все зависит от оператора. Если пользоваться сетью на общих основаниях, с обычной карточки - а так многие и делают чтобы экономить - то будьте готовы к тому что ответ может быть от мгновенного до ..... минут. А то и вообще не сможете в GPRS зарегистрироваться.
Для серьезных объектов покупают выделеный канал, где вам гарантировано предоставят очень быстрое GPRS соединение. Но и цены там совершенно другие. Так что или платим мало и никакой гарантии соединения, или имеем гарантированый канал за несколько большие деньги.
http://corp.mts.com.ua/rus/gprs_corporative_network.php
box415
Aug 14 2012, 07:48
Хотелось бы продолжить тему. М.б. у кого-то появился дополнительный опыт.
Возникла следующая проблема на SIM900R с версией В04 (В03 пока не проверяли). При закрытии сокета с оператором МТС в СПб неадекватно выполняются команды CIPCLOSE и CIPSHUT. Происходит это примерно в 20% случаев, преимущественно в периоды утренней и вечерней загрузки сети. При этом с другими операторами (Мегафон, Теле2, Билайн) проблем нет. Более того, нет проблемы и у SIM300 c MTC. Неадекватность выглядит следующим образом. Команда CIPCLOSE короткая завершается нормально, но не снимает DCD. Команда CIPCLOSE длинная зависает без ответа более, чем на 120 секунд. Если не использовать CIPCLOSE, а выдавать сразу CIPSHUT, то зависает без ответа эта команда более, чем на 120 секунд, а это предельный таймаут для команды по документации. При этом во всех случаях сервер при выдаче команд сразу фиксирует закрытие сокета. Конечно, можно все свалить на загруженность сети, но SIM300 в этих же условиях параллельно работает отлично. Все-таки есть подозрения на новую реализацию TCP/IP стека в SIM900R. Логи снятые с DEBUG-порта отправлены на китайскую сторону. Ждем ответа вторую неделю.
Alt.F4
May 10 2013, 13:22
Столкнулся с такой же проблемой, что и у box415 из предыдущего поста.
После AT+CIPCLOSE модем перестает реагировать на любые команды, пока на сервере не выйдет таймаут и сессия будет закрыта принудительно (у нас 10минут), либо до нажатия на POWERKEY (после чего выдает +PDP: DEACT, CLOSE OK и NORMAL POWER DOWN).
При вводе же AT+CIPCLOSE=1 ответ прилетает мгновенно и все работает как надо.
Вопрос: чем же все-таки отличается AT+CIPCLOSE от AT+CIPCLOSE=1 и почему при вводе первого сессия не закрывается?
Спасибо.
Цырен.
May 13 2013, 07:13
Цитата(Alt.F4 @ May 10 2013, 17:22)

Столкнулся с такой же проблемой, что и у box415 из предыдущего поста.
После AT+CIPCLOSE модем перестает реагировать на любые команды, пока на сервере не выйдет таймаут и сессия будет закрыта принудительно (у нас 10минут), либо до нажатия на POWERKEY (после чего выдает +PDP: DEACT, CLOSE OK и NORMAL POWER DOWN).
При вводе же AT+CIPCLOSE=1 ответ прилетает мгновенно и все работает как надо.
Вопрос: чем же все-таки отличается AT+CIPCLOSE от AT+CIPCLOSE=1 и почему при вводе первого сессия не закрывается?
Спасибо.
В случае с box415, было выяснено, что модуль просто выключался... Там проблема в источнике питания.
В вашем случае. Вы наблюдаете таймаут по нормальному закрытию (с подтверждениями). Таймаут у модуля - 2 минуты. В этот момент следите за NETLIGHT и STATUS, не дергайте модуль АТ командами.
CIPCLOSE=1(значение по умолчанию "0") означает быстрое закрытие без подтверждений от сервера. Модуль просто сбросит свой стек в начальное сосотояние. Об этом вы можете прочитать на стр.28 в приложенном файле.
Для просмотра полной версии этой страницы, пожалуйста,
пройдите по ссылке.