Причём здесь программирование?
Резонный вопрос, ведь написание софта для «мобильников» не самая распространенная область программистской деятельности. Но вся штука в том, что большинство (а скорее всего — все) операторов предоставляют возможность обмена короткими сообщениями между MT и внешними, по отношению к мобильной сети (PLMN – Private Local Mobile Network) устройствами, т. н. ESME (External Short Messages Entity), в качестве которого может выступать любое ПО, поддерживающее определенный протокол. Делается это с помощью определенных устройств, называемых SMSC (Short Messages Service Center), одним «концом» подключенных к PLMN, а другим — в сеть общего назначения, например TCP/IP (Internet). Вот как это выглядит:

Не обращайте пока внимание на аббревиатуру SMPP (к ней мы вернемся чуть позже), а вместо неё читайте «некоторый протокол для связи с SMSC». Хорошим примером ESME является последняя версия ICQ. Что? Уже кидали «мессаги» подружке на трубку? Так не пора ли теперь разобраться, как все это устроено?
Протоколы SMS.
Вот тут мы затронули достаточно скользкую тему. Дело в том, что хоть они и называются «протоколами», таковыми они на деле не являются: это отраслевые рекомендации разработчиков SMSC, которых довольно много. И если в части передачи сообщений по мобильным сетям особых разногласий не наблюдается: работает «настоящий» протокол SS7 (Signaling System Seven, тема для отдельного большого разговора), то в части доведения сообщений от ESME до SMSC каждый разработчик придумывает свой «протокол»; единственное требование к разработчику: публикация спецификаций. Упомянем самые популярные протоколы, кратко перечислив их отличительные черты.
SMPP
SMPP (Short Messages Peer-to-Peer) является, видимо, самым распространенным протоколом и разрабатывается SMPP Developers Forum (ничего общего с Open Source, просто организация такая). Один из, на наш взгляд, самых удобных протоколов, много возможностей, достаточно хорошо проработан. SMPP предлагает бинарную кодировку пакетов (впрочем, к этому мы еще вернемся). Используется многими операторами, в т. ч. British Telecom.
Протокол EMI (External Machine Interface) продвигает ETSI (кажется расшифровывается как European Telecommunication Standards Institute). Предлагает текстовую кодировку пакетов, также имеет развернутые возможности, но, на наш взгляд, неэстетичен. В различных диалектах используется многими провайдерами, точно — Swisscom'ом, и, вроде как, — NWGSM'ом.
SMS2000 aka SEMA
Тяжёлый протокол, разрабатывается SEMA Group. Однако, возможности большие. Предлагает на выбор бинарную, шестнадцатиричную и IA5 кодировку пакетов. Используется Vodafone. Оставляет неприятные воспоминания.
CIMD Тоже протокол... Напоминает EMI... ;)
Общий знаменатель. Несмотря на такое изобилие, суть работы всех протоколов сводится, что очевидно, к нескольким простым функциям (смотрим со стороны ESME):
Организация соединения с SMSC Отправка сообщений в PLMN Прием сообщений из PLMN Прием подтверждений доставки (delivery receipts)
Установка связи
Фактически, порядок работы следующий: соединяемся с SMSC и, поверх сетевого протокола, начинаем слать пакеты (называемые часто «командами» или «операциями») в формате выбранного нами SMS-протокола. Для простоты, будем опираться на самый распространенный случай, связь по TCP/IP, хотя многие модели SMSC поддерживают связь через, например, X.25 или PSTNA, а SMS-протоколы абстрагированы, насколько возможно, от деталей установки соединения.
Транзакционный механизм Для того, чтобы предоставить гарантию доставки, все SMS-протоколы используют транзакционный механизм, а проще говоря, подтверждения для каждой, испущенной (invoke) любой из сторон, команды. Получив команду, участник обмена (SMSC или ESME) обязан ответить на неё специальным пакетом, называемым в разных протоколах по-разному: response, result или ACK (от acknowledgement). Мы будем называть такие пакеты ACK (опять же, чтобы не путаться в терминах). Различают два типа ACK'ов: собственно ACK — положительный ответ и NACK — отрицательный (negative) ответ. NACK кроме указания на тот факт, что приключилась ошибка, передает еще и её код, прописанный в спецификации протокола. Вот как это выглядит в графике:

и наоборот
Каждая транзакция нумеруется инициирующей стороной, принимающая сторона использует переданный ей номер в ACK'е. Правила нумерации обычно свободные, указывается только диапазон допустимых номеров, для каждого протокола он, естественно, разный. Однако открытие двух транзакций с одним номером в рамках одной сессии, как правило, недопустимо. В случае неприхода ACK'а за определенное время (настраиваемое как на SMSC, так и на ESME) команда считается неуспешной и, в зависимости от логики работы, повторяется. Если противоположная сторона продолжает «молчать» в ответ на испущенные команды, соединение обычно разрывается.
Вывод
Теперь мы знаем о предмете достаточно, чтобы сформулировать задачи требующие решения для написания ESME клиента. Необходимо:
Иметь возможность установки соединения по TCP/IP с сервис-центром. Уметь формировать пакеты в формате выбранного нами протокола. (В скобках заметим, что, как правило, выбор протокола определяется не пристрастиями программиста, а жестко закреплен предоставляемым сервисом.)
Уметь «разбирать» (parse) пакеты в формате выбранного протокола. Мы здесь не упомянули одну важную «административную» задачу — подписание договора на обслуживание с поставщиком услуг сотовой связи. Однако, решение таких вопросов обычно лежит вне рамок программистской компетенции. В дальнейшем (в следующих статьях) мы покажем, как написать простое SMS- приложение, для отладки которого воспользуемся написанным нами же примитивным эмулятором сервис-центра. Оставайтесь с нами.