вибір протоколу
С.Кадаков
[email protected]
SMS-додаток. Частина 1. Глава 1 Вибір протоколу.
Що ж, ось і настала пора написати наше перше реально працююче SMS-додаток, ніж та займемося. Для "удобоваренія" ми розбили цю статтю на кілька частин: спочатку займемося деякими теоретичними питаннями (так, сущі дрібниці - опишемо протокол :), а потім, не відволікаючись, займемося кодуванням.
Минулого разу ми показали, як встановлювати зв'язок з Сервіс-центром, тепер же необхідно навчитися працювати власне з протоколом - формувати і "розбирати" пакети. Але перш, як легко здогадатися, необхідно вибрати протокол. Цю складну задачу ми візьмемо на себе;) і зупинимося на SMPP (Short Messages Peer-to-Peer). На користь такого вибору говорять не тільки особисті пристрасті, але і те, що даний протокол є наіблее широко розповсюдженний, відмінно пропрацьований і чудово документований. Крім того, не виключаючи можливості того, що читачам в реальності доведеться зіткнутися з іншими протоколами, відзначимо, що тут ситуація схожа вивчення іноземних мов: другий вивчати легше ніж перший, третій, ніж другий і т. Д.
Глава 2. Протокол SMPP. Огляд.
Протокол SMPP дозволяє. як не важко здогадатися, "зовнішнім" пристроїв обмінюватися повідомленнями бездротову локальну мережу (PLMN) за допомогою SMSC і визначає: Набір операцій для обміну між SMSC і ESME, званих також "командами" (command). Формат переданого пакета (PDU - Protocol Data Unit), асоційований з кожною з операцій. Формат відповідного пакета (ACK або responce) для кожної PDU. Дані, якими ESME повинна обмінюватися з SMSC в ході таких операцій.
Таким чином, викликом команди відповідає відправка PDU, тому ми іноді замість "викликати submit_sm" будемо говорити "послати submit_sm" і навпаки. Слід також звернути увагу на те, що кожна з команд в рамках сесії повинна бути підтверджена відповідним пакетом (ACK), єдиний виняток - alert_notification PDU (втім, ця команда нам на перших порах не знадобиться).
Процедура ініціалізації виконується за допомогою виклику однієї з команд bind_ *. bind_receiverbind_transmitterbind_tranceiver формат яких ми розглянемо трохи нижче. Таким чином, сесія може перебувати в наступних станах: OPEN - Встановлено сокетних з'єднання і посланий один із запитів bind_ *. BOUND_RX | BOUND_TX | BOUND_TRX - Виконана одна з команд bind_ *. З'єднання готове до прийому | передачі | прийому і передачі. CLOSED - Виконана команда unbind (розглянемо пізніше) і з'єднання закрито. Крім того, SMSC в будь-який момент може послати команду outbind. У відповідь на цю команду ESME зобов'язана знову виконати один із запитів bind_ *. Правда, в реальній практиці ця команда зустрічається рідко, але до її обробці слід бути готовим.
Команди (PDU) SMPP
Протокол SMPP версії 3.4 надає наступний набір команд:
SMPP PDU Name Required SMPP Session State Issued by ESME Issued by SMSC
Команди з суфіксом _resp означають responce, т. Е. ACK (ми також вживаємо термін квитанція, і говоримо, що ACK "квитирующего" команду). Жирним позначені команди, які ми розглянемо (інші в нашому простому випадку нам поки не знадобляться).
Режими (Modes) повідомлень.
Протокол SMPP v3.4 підтримує три режими обміну повідомленнями. Ми не будемо на цьому особливо зупинятися, просто згадаємо, що в подальшому будемо працювати в т. Н. Store and Forward Message Mode. В даному режимі повідомлення спочатку зберігається в базі даних SMSC, а потім робляться спроби його доведення, і, в залежності від запиту, ESME повідомляється про досягнення повідомленням фінального стану (доведено / не доведена). Підтримуються також Datagram Mode і Transaction Mode. про які можна прочитати у відповідній документації.
Типи даних SMPP
Все що визначаються протоколом PDU являють собою сукупність полів певних типів, збудовані один за одним в певному порядку. При роботі в мережі прийнято використовувати поняття октет (octet) - сукупність восьми бітів (то що прийнято називати в програмуванні байтом) для того, щоб підкреслити "восьмибитового". Все що визначаються SMPP типи прив'язані до октету. Ось вони: Integer - беззнакову ціле з вказаною в кожному конкретному випадку довжиною в октетах. C-Octet String - Серія ASCII літер, завершена нулем. C-Octet String (Decimal) - Серія літер (0-9), завершена нулем C-Octet String (Hex) - Серія літер (0-F), завершена нулем. Octet String - Серія октетів, що не обязятельно завершена нулем. TLV - Tag-Length-Value. Використовується для необов'язкових параметрів. Даний тип виник через необхідність розширювати вже існуючі команди зі збереженням зворотної совместімості.Поскольку ми не збираємося такі використовувати :), то і зупинятися на цьому не будемо, хоча питання, взагалі кажучи, важливий. Про TLV можна прочитати в специфікації протоколу.
Кожен пакет (PDU) складається з двох частин: Заголовок (header). Обязательная.Тело (body). Необов'язкова. Формат заголовка загальний для всіх PDU.
Тема має довжину 16 октетів і складається з 4-х полів: Command length - Довжина. 4 октету. Повинен містити загальну довжину пакета, включаючи і це поле. Command id - Ідентифікатор команди. 4 октету. Вказує на тип команди. Приймає значення від 0x0 до 0x1FF для команд і від 0x800000000 до 0x8000001FF для відповідей (ACK). Кожен пакет, який представляє собою ACK має command_id такий же, як і квітіруемая команда, але з виставленим 31-м бітом Command status - Статус команди. 4 октету. Використовується в ACK'ах, в командах виставляється в 0x0. Sequence number - Номер послідовності. У кожному конкретному випадку містить унікальний номер окремої команди (не плутати з command_id) і дозволяє асоціювати ACK з командою. Призначається испускающей стороною довільно з діапазону 0x1-0x7FFFFFFF. Повтор даного номера в рамках однієї сесії, взагалі кажучи, не допустимо. ACK повинен мати той же номер, що і квітіруемая команда. Деякі PDU (зокрема, більшість ACK'ов) складаються тільки з заголовка і цієї інформації виявляється достатньо.
Глава 3. Проміжний підсумок
У цій частині ми обговорили виключно важливе питання, а саме: структуру протоколу. Сподіваємося, поки непорозумінь не виникло.