С.Кадаков
sgerr@clubpro.spb.ru
SMS-приложение. Часть 5. "Разбор полетов". Вопросы наших читателей.

Меня вот спросили: "А почему это Вы себя во множественном числе именуете?". Отвечаю: это не то что вы подумали (хотя, может и стоит у психоаналитика проконсультироваться на предмет мании величия ;), а издержки опыта "научнописания". В статьях считается хорошим тоном писать во множественном числе, имея ввиду коллектив авторов. Так и тут, предполагалось, что данный цикл я буду вести не в одиночку, посему и задан такой "околонаучный" тон. Однако так выходит, что заниматься этим мне приходится в "единственном числе", посему, принимая во внимание данное замечание, в дальнейшем обязуюсь повествовать от собственного лица (другого не имею :) пока-таки не появятся помощники.

В данной статье мы (с Вами :) побеседуем о том, как на самом деле устроены эти так называемые ESME и для чего, собственно, они предназначены. Вообще говоря, это нужно было бы сказать с самого начала, но я решил, что сначала неплохо дать читателю (т. е. Вам) присмотреться, а уж потом "делать строгое лицо". Итак, казалось бы чего проще -- подцепил к COM-порту радиопад, типа SIEMENS, и вещай себе прямо в эфир (по сути, такая конструкция эквивалентна "домашнему" сервис центру). В некоторых случаях подобный "агрегат" представляется приемлемой альтернативой, пока речь не заходит об интенсивности траффика. Именно при построении "профессиональных" сервисов, рассчитанных на охват большой аудитории, ESME и будет являться компонентой сервисных систем.

Так что же такое ESME? Для того, чтобы строго ответить на этот вопрос придется обратиться к известной OSI/ISO модели (рис. 1).

Рис. 1. Модель OSI
Ниже приведена таблица, показывающая, как на ней "размещается" ESME. Для примера приведены стэки протоколов для Microsoft Networking и регулярного TCP/IP приложения, например почтового клиента. Мы, по-прежнему, обсуждаем ESME, связывающееся с сервис центром по протоколу TCP/IP.

Теперь видно, что собственно ESME занимает то же положение на стэке, что и регулярный TCP/IP клиент. Правда, если ESME не оформлено в виде библиотеки, оно может простираться и на самый верхний -- седьмой -- уровень. Таким образом, самым верхним подлежащим уровнем для ESME будет реализация TCP/IP стэка операционной системы, что мы собственно и видели. К слову, сама программа (библиотека) может быть и не так жестко разбита на "слои", но здесь я явно их выделил. Давайте обсудим эти уровни по отдельности. Session layer предназначен для решения задач, не относящихся собственно к передаче данных. В этот круг задач могут входить аутентификация сторон, восстановление физических или логических соединений, организация двунаправленных потоков (bidirectional traffic), token management, синхронизация и пр. Presentation layer отвечает за преобразование данных.

Общая структура dumb_esme представлена на картинке. Перейдем к обсуждению назначения классов, вошедших в состав приложения опираясь на уровни модели OSI. Session layer.

В нашем простом примере этот уровень не представлен со всей фундаментальной четкостью, часть функций (в т. ч. решение о закрытии соединений) делегирована основной функции (main), а восстановление соединений и поддержание внутренних циклических (FIFO) буферов и вовсе опущено. В реальных проектах приходится организовывать такие "очереди октетов" по той причине, что (в отличие от X.25) TCP/IP не гарантирует что одним вызовом recv мы получим ровно один отправленный протокольный пакет и целиком. Типичная ситуация, проявляющаяся в частности при больших загрузках: за один вызов recv приходит два целых пакета и "кусок" третьего. Разумеется, в связи с гарантированной доставкой данных по TCP-каналу, недостающий "кусок" будет получен следующим вызовом, но, возможно, еще с чем-то "на хвосте". Ситуацию, как я уже сказал, решают созданием FIFO буфера: модуль, непосредственно оперирующий сокетом, пишет в "хвост" такого буфера, а вышестоящий модуль, "откусывает помаленьку" с "головы". Кроме того, в протоколе SMPP, в отличие, скажем, от EMI или SIMD, не предусмотрены маркеры начала и конца пакета, так что при возникновении "мусора" в канале "ловля" начала следующего неиспорченного пакета превращается в серьезную (вообще говоря -- неразрешимую) проблему и проще переустановить соединение, сбросив буфер. Вообще говоря, достаточно в заголовке пакета указать неверную длину, чтобы вывести канал из строя.

В нашем простом примере проблема частично решена путем обработки входящих пакетов "в два удара": сначала обрабатывается заголовок пакета (длина которого строго фиксирована), а потом принимается из канала ровно столько октетов, сколько указано в заголовке. К слову, и при работе со внутренним буфером также приходится сначала обрабатывать заголовок, ибо именно в нем указан тип команды. Возвращаясь к модели OSI отметим, что все же многие функции обсуждаемого уровня инкапсулированы в нашем примере в двух классах.

Это простая классовая оболочка вокруг системной реализации протокола TCP/IP, именно он оперирует непосредственно с сокетом. В реальном проекте, скорее всего, здесь был бы реализован буфер FIFO. Интересной задачей могла бы являться реализация данного класса как наследника basic_iostream из стандартной библиотеки, что нибудь наподобие sockstream...

Наследник класса connector, выполняющий большинство функций, характерных для Session Layer, как то: аутентификацию (посредством SMPP bind), разбор и проверку заголовков пакетов, поддерживает внутреннюю нумерацию команд SMPP. Обращаясь к реальным проектам, следует сказать, что этот класс -- самое место для управления восстановлением соединения для ESME работающих в непрерывном (ждущем) режиме. Стоит также заметить, что есть все основания задуматься о вынесении функциональности данного класса в отдельный поток исполнения (thread).

Представлен двумя классами transmitter и receiver. Как явствует из названия, эти классы (будучи оба наследниками класса smpp_connector) инкапсулируют особенности сессий в состояниях BOUND_TX и BOUND_RX, занимаются распаковкой и упаковкой пакетов (я говорю пакеты, подразумевая, конечно же PDU) и переправляют их "вверх" приложению и "вниз" -- в сокет. Интерфейс с приложением поддерживается с помощью двух структур данных: message, являющейся абстракцией как для входящего, так и для исходящего сообщений, и status_info, отображающей факт изменения состояния сообщения (принято/не принято, доведено/не доведено).

Вот, собственно, и вся реализация протокола. Остальные классы, вошедшие в проект являются вспомогательными, их суть видна из названий (и откомментирована в коде).

Надеюсь, данным циклом статей, не затрагивающим, как я уже сказал, все "интересные" вопросы мне удалось показать технику написания такого класса приложений. Я старался обсудить наиболее общие вопросы, не привязываясь к определенной платформе и не "отступая далеко" от реальных проектов, в создании которых мне удалось принять участие (один из таких, кстати, оправдывая описанный подход, в настоящее время трудится в непрерывном режиме, пропуская в пиках до 5 млн. сообщений в сутки).

Что же "осталось за скобками"? Да довольно многое. Мы никак не обсудили передачу двоичных данных (графики, мелодий), сосредоточившись на SMPP, оставили без внмания другие протоколы, не коснулись интересных особенностей программирования под конкретные OS. Честно говоря, я не могу сейчас сказать, чем будет продолжен этот цикл статей, посему, это отличный повод для аудитории сделать заявки. Надеюсь на вашу активность.