суббота, 20 февраля 2010 г.

Поговорим об SMS Protocol Data Unit

Решил поближе познакомиться с форматом SMS сообщений. Далее я напишу несколько закономерностей/законов, которые помогут мне написать достойную библиотеку c виртуозной архитектурой для работы с SMS PDU. Только учтя все особенности формата, возможно создать в меру сбалансированную библиотеку. Под балансировкой я понимаю выбор достаточного числа классов, структур, перечислений, способов взаимодействия компонентов между собой и интерфейса для использования библиотеки.


В статье используются сокращения:
SME - Short Message Entity (Модуль мобильного устройства)
SMSC - SMS-Centre (Центр обработки сообщений)
PDU - Protocol Data Unit (Протокольная единица данных)

В первую очередь примечательно, что имеется 6 типов сообщений:
+ SMS-SUBMIT
+ SMS-SUBMIT-REPORT
+ SMS-DELIVER
+ SMS-DELIVER-REPORT
+ SMS-STATUS-REPORT
+ SMS-COMMAND (посылка специальных команд от SME к SMSC)

Использование первых пяти типов поясняет эта схема:
SMS PDU Types

Тип сообщения хранится в 2-х битах первого байта. Неправда ли, маловато 2-х битов для хранения 6 возможных значений? Конечно мало, но если вы знаете кто это сообщение сгенерировал, то вам остаётся прочитать из 2-х бит всего 3 возможных значения.

Типы сообщений от SME:
( 0 1 ) SMS-SUBMIT
( 0 0 ) SMS-DELIVER-REPORT
( 1 0 ) SMS-COMMAND

Типы сообщений от SMSC:
( 0 1 ) SMS-SUBMIT-REPORT
( 0 0 ) SMS-DELIVER
( 1 0 ) SMS-STATUS-REPORT

Первый байт всегда содержит флаги/индикаторы. Все данные пакета измеряются в байтах, некоторые переменной длинны. То, какие флаги присутствуют в пакете - определяется типом сообщения. Присутствующие поля определяются типом пакета и флагами.

Принципы планируемой библиотеки:
1) Каждому типу сообщения - свой класс, наследованный от базового. Каждый из них будет иметь свои флаги/индикаторы и обязательные поля. Некоторые флаги/индикаторы будут реализовываться отдельными классами, и будут иметь указатели на классы связанных с ними полей. Базовый класс будет уметь определять тип сообщения и создавать экземпляр соответствующего класса. [Напрашивается применение предыдущего поста про "кастование от родителя к наследнику"]
2) Классы храня данные только в самом PDU. (никаких промежуточных полей)
3) Каждое из полей наследуется от универсального класса "единицы данных". Имеет встроенные методы, по изменению размера и поля и перемещению данных в памяти. Обладает указателем на следующую "единицу данных", при изменении своего размера, заставляет двигаться следующую за ним "единицу данных".
4) [В разработке]

Комментариев нет: