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

а "at+cipshut" не пробовали?
я именно этой командой пользуюсь. проблем не замечал
RadikX
Неверное я неправильно сформулировал вопрос. Я имею ввиду команды отличаются только ответом: сразу в быстром и по факту в медленном. Или все же он реально его как-то обрывает и я его могу тут же использовать снова? Проверить на стенде сложно: ситуация происходит несколько раз в сутки.

"а "at+cipshut" не пробовали? "

AT+CIPSHUT, если не ошибаюсь, закрывает полностью GPRS сессию, что приводит к округлению трафика.
Aurochs
Цитата(RadikX @ Mar 26 2012, 12:30) *
выяснилось что задержки между запросом и ответом могут достигать почти 20 сек, что катастрофично.

Вам повезло с провайдером. Мне приходилось наблюдать задержки до полутора минут.
И в чем катастрофа, если не секрет?

Цитата(RadikX @ Mar 26 2012, 12:30) *
Вопрос: чем плох быстрый способ закрытия соединения и какие проблемы может принести его применение?

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


Охренеть... wacko.gif

Приборы используются в охране. Все жестко.
M_Z
Цитата(RadikX @ Mar 26 2012, 13:34) *
AT+CIPSHUT, если не ошибаюсь, закрывает полностью GPRS сессию, что приводит к округлению трафика.

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

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

Используйте UDP. Закрываться/открывыться будет мгновенно.

Цитата
а "at+cipshut" не пробовали?

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

Нафига полумеры? Лучше рубить по питанию.

+1 sm.gif На все 100% поддерживаю!
RadikX
Нашел документальные нормы задержек. Может кому будет интересно...
Нажмите для просмотра прикрепленного файла

Нажмите для просмотра прикрепленного файла

SDU - Service Data Unit. Модули данных GPRS

Как видно задержки в 1.5 минуты это еще очень хорошо.
CADiLO
>>> Чисто интуитивно, я думаю, это как-то связано с тем что GPRS в GSM вторичен по отношению к голосовому каналу.

Абсолютно верно. И если сота будет перегружена голосовыми звонками, то все слоты отдадут под них.
Поэтому в охранные системы часто ставят карточки 2х операторов и пользуются резервным каналом.
RadikX
Цитата(CADiLO @ Mar 27 2012, 09:05) *
Поэтому в охранные системы часто ставят карточки 2х операторов и пользуются резервным каналом.


Ну так то оно в принципе и сделано. Одна симка резервная. Однако иметь две АКТИВНЫЕ симки это накладно - надо иметь два модуля и оплачивать два соединения. А регистрация в сети, потом регистрация в GPRS - опять потери времени. Я думаю что решить программными средствами здесь не получится. GPRS в охране может использоваться только как вторичный канал, либо где 10 минут приемлемое время.

Кстати нашел вот такую команду: AT+CIPQRCLOSE, в которой как раз и можно настроить быстрое закрытие сокета: с одним или двойным подтверждением.
CADiLO
Не нужно две активных - я такое в единичных устройствах видел. Вполне хватает переключения.

>>>А регистрация в сети, потом регистрация в GPRS - опять потери времени.

Вы на время слишком не упирайте, потому как если сеть не даст слоты, то и две активных карточки не помогут.
Поэтому реальное время реакции на срабатывание вполне укладывается в 5-7 минут.
Ведь многие даже не держут модуль постоянно в активном режиме, а включают его только после срабатывания сигнализации или по времени чтобы сбросить данные.
andrewlekar
Вот у меня с закрытием проблем особых не было. Я использую во-первых CIPSHUT, а во-вторых в нормальных условиях не закрываю соединение. А вот с открытием сессии... То ли CSTT, то ли CIICR вешает модуль намертво на минуту где-то, при некоторых условиях. Не смертельно, но весьма неприятно.
_Артём_
Цитата(CADiLO @ Mar 27 2012, 10:47) *
Поэтому реальное время реакции на срабатывание вполне укладывается в 5-7 минут.

Ничего себе время рекции.


Цитата(CADiLO @ Mar 27 2012, 10:47) *
Ведь многие даже не держут модуль постоянно в активном режиме, а включают его только после срабатывания сигнализации или по времени чтобы сбросить данные.

Лучше с sleep-e держать. Или там GPRS-контент/сокет теряется?
CADiLO
Как я уже написал, все зависит от оператора. Если пользоваться сетью на общих основаниях, с обычной карточки - а так многие и делают чтобы экономить - то будьте готовы к тому что ответ может быть от мгновенного до ..... минут. А то и вообще не сможете в GPRS зарегистрироваться.
Для серьезных объектов покупают выделеный канал, где вам гарантировано предоставят очень быстрое GPRS соединение. Но и цены там совершенно другие. Так что или платим мало и никакой гарантии соединения, или имеем гарантированый канал за несколько большие деньги.

http://corp.mts.com.ua/rus/gprs_corporative_network.php
box415
Хотелось бы продолжить тему. М.б. у кого-то появился дополнительный опыт.
Возникла следующая проблема на SIM900R с версией В04 (В03 пока не проверяли). При закрытии сокета с оператором МТС в СПб неадекватно выполняются команды CIPCLOSE и CIPSHUT. Происходит это примерно в 20% случаев, преимущественно в периоды утренней и вечерней загрузки сети. При этом с другими операторами (Мегафон, Теле2, Билайн) проблем нет. Более того, нет проблемы и у SIM300 c MTC. Неадекватность выглядит следующим образом. Команда CIPCLOSE короткая завершается нормально, но не снимает DCD. Команда CIPCLOSE длинная зависает без ответа более, чем на 120 секунд. Если не использовать CIPCLOSE, а выдавать сразу CIPSHUT, то зависает без ответа эта команда более, чем на 120 секунд, а это предельный таймаут для команды по документации. При этом во всех случаях сервер при выдаче команд сразу фиксирует закрытие сокета. Конечно, можно все свалить на загруженность сети, но SIM300 в этих же условиях параллельно работает отлично. Все-таки есть подозрения на новую реализацию TCP/IP стека в SIM900R. Логи снятые с DEBUG-порта отправлены на китайскую сторону. Ждем ответа вторую неделю.
Alt.F4
Столкнулся с такой же проблемой, что и у box415 из предыдущего поста.
После AT+CIPCLOSE модем перестает реагировать на любые команды, пока на сервере не выйдет таймаут и сессия будет закрыта принудительно (у нас 10минут), либо до нажатия на POWERKEY (после чего выдает +PDP: DEACT, CLOSE OK и NORMAL POWER DOWN).
При вводе же AT+CIPCLOSE=1 ответ прилетает мгновенно и все работает как надо.

Вопрос: чем же все-таки отличается AT+CIPCLOSE от AT+CIPCLOSE=1 и почему при вводе первого сессия не закрывается?
Спасибо.
Цырен.
Цитата(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 в приложенном файле.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.