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

[ISG2015]

Необходимо разработать систему с передачей данных c использованием технологии GPRS.
Выбор пал на модемы SimCom

Готовых решений не встречал (готов за разумные деньги приобрести) и поэтому вынужден заняться изобретением велика
Несколько вводных вопросов относительно темы:

1. Можно ли организовать GPRS канал связи используя только АТ команды, не пользуясь Embedded AT?
2. После прочтения мануалов и даташитов на тот же Sim900 реализуемо своими силами?
3. Как учесть все особенности и нюансы каждого GSM оператора используя только одни АТ команды?

Буду оч. признателен за любые советы и помощь.

[GeGeL]

разрыв GPRS - оператор округлит объем в большую сторону

Не все операторы это делают, и объем округления тоже разный. Надо смотреть индивидуально, и учитывать время между активностью. Дело в том, что всегда имеется фоновый IP-спам, который тарифицируется в случае, если сисоп назначает модую "белый" IP. Поэтому решение о разрыве надо принимать по факту, исходя из задачи и условий.

а в произвольное время, то не факт, что они дойдут т.к. фаервол провайдера может просто забыть об этой сессии.

По условию ТС сервер поднят на белом IP. Поэтому, независимо от того, какой IP назначен сисопом модулю, первый же и любой пакет, отправленный с модуля на сервер в любое время, инициирует фаервол провайдера, и будет выпущен наружу. Т.к. по определению на серверной части нет фаервола, то он будет доставлен. NAT со стороны провайдера будет инициализирован, и сервер имеет около 3 минут на ответ. По истечение этого времени NAT провайдера закроет соединение, и сервер никак не достучится до клиента, аж до следующей активности клиента. Если передачу "клиент-сервер" по условию задачи инитит только клиент, то все ОК. Если требуется возможность активации клиента со стороны сервера, то, как по мне, проще сделать это входящем звонком клиенту (при разумном количестве клиентов и редких случаях, например, конфигурирование клиента), чем держать все время отрытую TCP-сессию.

Если начать реализовывать все эти проверки доставки на UDP, то в конце концов просто заново изобретешь TCP.

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