GPRS для чайников Опции

[ISG2015]

Можно пойти пацанским путём: использовать PPP и внешний tcp стек, благо нынче и железа подходящего полно и софт есть
например lwIP и STM32 и любой модем включая проводные))

Не понял. А для чего именно РРР и внешний стек? Мне интересно использовать GPRS так как во многих местах и случаях это единственный способ связаться с сервером.
lwIP и STM32 это как раз сейчас в работе, но это канал связи там где есть инет.

Гораздо проще использовать UDP. На сервере держите всего один сокет, при получении пакета от клиента проверяете контрольную сумму, сохраняете данные в базе, возвращаете КС на IP/порт отправителя.
Алгоритм клиента: если есть новые данные, поднимаете GPRS, отправляете данные и КС, ждете ответа 2-3 сек, если нет, то повторяете 3-5 раз. После получения подтверждения или исчерпания попыток рвете GPRS (если сеансы реже 5-10 мин), или оставляете, если чаще.
Преимущества: не нужна поддержка открытой ТСП-сессии, нет процедур конекта/дисконекта, гарантийность доставки и таймауты организованы под задачу, а не универсал. Т.к. у вас статический IP на сервере, не надо ресолвить доменное имя. Трафик, как минимум, в 1.5 раза меньше, чем в случае с ТСП.
С помощью OpenCPU/EAT это реализуется за час. И, кстати, почему Вы не хотите использовать EAT? Если нет желания изучать все команды, можете использовать всего одну - отправку данных в виртуальный порт. И один обработчик - получение данных с него. А дальше отсылайте АТ-команды, и получайте ответы так же, как и в случае с внешним процессором. И надежней, и дешевле, и код переносимый будет.

Что касается канала сервер-диспетчер, то тут как угодно, например, SQL.

Спасибо за совет.
Во-первых: мне нужно не проще а надежнее, стабильнее и прозрачнее. То есть, канал связи обязательно должен быть построен с использованием правильной архитектуры. Если не будет хватать знаний и навыков - будем вникать. Алгоритм клиента планируется в принципе иной. Я хочу отправлять и принимать данные на клиенте через БД на серверной стороне. Таким образом что для отправки данных клиент пишет в БД, а для получения информации ее (БД) читает. С другой стороны сервер работает с этой же БД. Таким образом клиент работает не с сервером а с БД на сервере. Это важно.
А вот трафик да, тут нужно конечно думать. Сегодня пришло письмо от оператора связи в котором мне дали понять что я не смогу в режиме "онлайн" мониторить расход трафа. Только в начале месяца за прошлый статистика.
OpenCPU/EAT хорошие и нужные вещи, но наверное не в нашем случае. Для нас GPRS это канал связи, а модем портал для работы в этом канале. Не хочется усложнять.

[CADiLO]

>>> Сегодня пришло письмо от оператора связи в котором мне дали понять что я не смогу в режиме "онлайн" мониторить расход трафа. Только в начале месяца за прошлый статистика.

Так небось это на стандартный "разговорный" пакет. Спросите у оператора пакет для M2M - они специально ориентированны на передачу данных и мониторинг трафика должен быть.

Примеры таких пакетов у нас

http://www.kyivstar.ua/ru/ck-238/business/...s/messages/m2m/
http://corp.mts.com.ua/rus/telematic_tariff.php

и в России

http://www.corp.mts.ru/telematika/tariffs/telematika/

Гибкие условия тарификации Интернет - трафика:
оплата по факту потребления - для небольших объемов передаваемых данных;
пакеты GPRS трафика – для более интенсивного обмена данными;
безлимитные опции;
округление GPRS трафика 1 Кбайт - вы не платите за трафик, который не потребляли;


И если будете делать свой внешний стек, то тогда посмотрите в сторону 3G модуля SIM5350.
Там нет встроенного TCP/UDP стека, зато умеет работать в два потока IP/V4 и IP/V6 в любой комбинации.
Идеальный модуль под внешний стек - быстрый и для 3G недорогой.

•IPV4/IPV6 Dual protocol stack
•Mutil-PDP
•Secondary PDP active

[ISG2015]

Смотрю много решений с 2мя SIM-картами. Используя одни АТ команды для TCP коннекта, необходимо будет как-то со стороны внешнего процессора переключать карточки?

И если будете делать свой внешний стек, то тогда посмотрите в сторону 3G модуля SIM5350.
Там нет встроенного TCP/UDP стека, зато умеет работать в два потока IP/V4 и IP/V6 в любой комбинации.
Идеальный модуль под внешний стек - быстрый и для 3G недорогой.

Почитаю о нем. Не совсем понял, что значит нет встроенного TCP/UDP стека и зачем мне два потока IP/V4 и IP/V6 в любой комбинации?
А вот поддержка 3G это здорово. В любом случае это будущее.

[p_kav]

А я бы не рекомендовал 3G для автономных и удаленных устройств. Покрытия 3G гораздо хуже 2G, поэтому энергопотребление будет намного выше, а также будут спонтанные переключения между 3G и 2G, во время которых связь будет теряться. 3G нужен только там, где требуется передавать большие объемы данных.

[GeGeL]

Во-первых: мне нужно не проще а надежнее, стабильнее и прозрачнее.

Так это тесно коррелирует: чем оно проще, тем все остальное перечисленное.

OpenCPU/EAT хорошие и нужные вещи, но наверное не в нашем случае. ... Не хочется усложнять.

Как раз наоборот - упрощать. Но это кому как, на любителя, навязывать не буду.

Алгоритм клиента планируется в принципе иной. Я хочу отправлять и принимать данные на клиенте через БД на серверной стороне. Таким образом что для отправки данных клиент пишет в БД, а для получения информации ее (БД) читает. С другой стороны сервер работает с этой же БД. Таким образом клиент работает не с сервером а с БД на сервере. Это важно.

Несколько раз перечитал, но так и не понял. Понятно, что имеется мобильный клиент с GSM-модулем. Понятно, что имеется постоянно работающий сервер с белым IP и БД на борту. Еще имеется диспетчер, подключенный к серверу, но это не важно.
Вопрос в том, кто инициирует обмен "клиент <> сервер"? В варианте с UDP клиент может первым послать на сервер пакет в любое время, и затем обмениваться данными с БД сервера. Если же обмена нет длительное время (>3 мин), то сервер не сможет первым связаться с клиентом и должен дождаться пакета от клиента. Если это допустимо по условиям задачи, то сохраняйте в БД сервера необходимые данные для клиента (переданные диспетчером), и они будут доставлены клиенту при первой же его активности.
Кроме того, "расшевелить" клиента также можно входящим звонком: после звонка клиент тот час отправляет пакет на сервер, тем самым инициируя обмен по запросу диспетчера, и забирает с сервера заготовленные для него данные.

[x893]

GSM модулю по барабану сколько карт - их можно внешним процессором переключать, только првильные параметры GPRS надо давать по IMSI коду. Модуль GSM можно любой использовать - главное что бы работал (не все модули одинаково хороши). БД и прочая лабуда для GSM - как рыбе зонтик.
Можно TCP/UDP, но мастера php/aspx/... могут и через http всё реализовать - разницы нет.
Вообще не понятно в чем проблема - примеров и кодов готовых - тонна.

[ISG2015]

Если же обмена нет длительное время (>3 мин), то сервер не сможет первым связаться с клиентом и должен дождаться пакета от клиента.

Доброе! Сервер НЕ будет связываться с клиентом вообще. Я хочу отказаться от модели в которой сервер общается с клиентом напрямую.
Клиент передает данные на сервер записывая информацию в БД. Получает информацию читая из БД.
БД тут только для некоторого удобства и простоты, как бы это не казалось странным на первый взгляд.

Я на самом деле советуюсь с вами, и далеко не гуру в принципе.

[ISG2015]

GSM модулю по барабану сколько карт - их можно внешним процессором переключать, только првильные параметры GPRS надо давать по IMSI коду. Модуль GSM можно любой использовать - главное что бы работал (не все модули одинаково хороши). БД и прочая лабуда для GSM - как рыбе зонтик.
Можно TCP/UDP, но мастера php/aspx/... могут и через http всё реализовать - разницы нет.
Вообще не понятно в чем проблема - примеров и кодов готовых - тонна.

Я и не говорю что проблема. Но очевидно что не все так просто.
На данный момент у меня есть понимание многих из ранее заданных вопросов. Есть и темные "места". Вот например я не понимаю на сколько это правильно/разумно и эффективно держать открытой TCP сессию открытой долго. Если таких сессий будет тысячи на одном сервере ,то как это отразится на работе системы? Вопросы ламерские, но ответы на них для меня не столь очевидны.

[p_kav]

Количество никак не отразится, если памети в нем не 128 Мб. Сервер напрягается по количеству пакетов в секунду и запросами к БД. Чтобы существенно напрячь его по трафику нужны миллионы клиентов, а вот как его напрягут запросы к БД зависит исключительно от правильности написания этих запросов программистами и правильности настройки СУБД сисадмином. В целом, VPS за 5 долларов в месяц с 512 Мб памяти должен без проблем вытянуть тысяч 5 клиентов, присылающих информацию раз в минуту, если сервеную часть писали нормальные программисты.

[RadikX]

Количество никак не отразится, если памети в нем не 128 Мб. Сервер напрягается по количеству пакетов в секунду и запросами к БД. Чтобы существенно напрячь его по трафику нужны миллионы клиентов, а вот как его напрягут запросы к БД зависит исключительно от правильности написания этих запросов программистами и правильности настройки СУБД сисадмином. В целом, VPS за 5 долларов в месяц с 512 Мб памяти должен без проблем вытянуть тысяч 5 клиентов, присылающих информацию раз в минуту, если сервеную часть писали нормальные программисты.

Открытые TCP сессии однозначно зло! Особенно если клиенты цепляются по GPRS. Клиент должен подключиться, сделать свое дело и отпустить сервер. Когда клиентов больше 1000-1500 начинает очень заметно ощущаться "мертвые души" соединений, если, конечно, сервер сам не будет по таймауту неактивности их закрывать. Дело не в трафике, а в количестве одновременно существующих соединений.

[p_kav]

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

[GeGeL]

Помнится, ТС заказывал надежнее, стабильнее и прозрачнее. А если еще и инициализация соединения "клиент <> сервер" нужна только со стороны клиента, то тут сам бог велел использовать UDP, сразу решается масса проблем.
В клиенте отпадает необходимость TCP-конекта/реконекта и проверять, не отвалился ли сервер. Нет постоянного расхода трафика на KeepAlive.
В модуле на старте:
- инициируете GPRS;
- создаете UDP-сокет;

Когда есть данные к отправке, упаковываете их в пакет, сопровождая crc и просто отсылаете на сервер, запоминаете crc, запускаете таймер и счетчик повторов. При истечении таймаута дублируете пакет. По исчерпании попыток пингуете 8.8.8.8. пару раз. По истечении таймаутов ресетите модуль.
При получении данных с сокета проверяете: если от 8.8.8.8, то пинг ОК, если с IP сервера, то сверяете crc в ответе с запомненной, если ОК, то завершаете.
Ответ сервера содержит crc полученных данных, данные для клиента, и общее crc пакета.

На сервера запускаете легковесный демон, написанный на голом С + легковесная С-библиотека SQL. В цикле опрашивате единственный открытый UDP-сокет. Если получен пакет, сверяете crc, извлекаете данные из полей пакета и пишете в БД, затем читаете с БД данные для этого клиента, распихиваете по полям, отдельно возвращаете crc принятого пакета, и отправляете на IP-порт, откуда пакет пришел.

Диспетчер работает с серверной БД обычным способом, тут ничего сложного нет.

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

[ISG2015]

Да, пожалуй соглашусь: UDP это то что мне подходит.
А зачем пинговать 8.8.8.8 ? Ведь если мне не отвечает сервер, то все остальное мне фиолетово так как нет канала связи. Да, есть инет, но сервак-то "валяется")

У меня статический адрес у сервера. Но он в силу разн. причин и обстоятельств может быть изменен. У клиента же зашит один фиксированный адрес. Может быть правильнее клиенту записывать/указывать адрес через некоего посредника? Люди для сайтов покупают доменное имя, и таким образом абстрагируются от всех вопросов с IP адресами.

Переписал сервер для работы с UDP сокетом. Модем SIM900 при создании сессии указываю UDP вместо TCP. Сутки почти модем отсылает с периодом в 20 с небольшой пакет на сервер. Не отваливается. С TCP было по-другому: сессия отваливалась в течении небольшого промежутка времени.

[rx3apf]

Люди для сайтов покупают доменное имя, и таким образом абстрагируются от всех вопросов с IP адресами.

Вариант - воспользоваться бесплатным DNS-сервисом. Который, правда, вдруг может стать платным, и придется искать замену, поэтому жестко зашить не получится...

[p_kav]

ISG2015
Можно зашить в EEPROM 3 бесплатных доменных имени и при подключении перебирать их по очереди, а в случае проблем с каким-то из них просто отсылать клиенту информацию о новых доменах, чтобы он у себя в памяти их обновил.

А TCP-сессия отваливалась именно при отправке данных каждые 20 секунд? Очень странное поведение.