В мире сложно найти что-либо идеальное. Протокола SMPP также не лишен некоторых изъянов. Опишу свои проблемы с этим протоколом. Надеюсь кому-то это поможет в принятии правильных решений.
Первый, самый проблемный недостаток: потеря message_id при разрыве соединения. Страдают от этого операции отправки (submit_sm и т.п.) для которых не успел прийти ответ. Протокол не содержит встроенных средств восстановления утерянных идентификаторов. Как следствие, когда придет статус сообщения, его не к чему привязать. Более того, неизвестно принял ли это сообщение SMSC.
Если обмен осуществляется в синхронном режиме, то потеряется только одно сообщение. Но если работа производится в асинхронном режиме, тогда потери могут быть существенными.
Этот недостаток SMPP, пожалуй, единственный нерешаемый средствами протокола из тех, которые я могу припомнить. Проблема, конечно, решается но не стандартизованными методами.
Остальные недостатки связаны с проблемами реализации. Их решении, как правило, заключается в достижении договоренности между SMSC и SMPP-клиентом и не выходит за рамки спецификации.
Второй недостаток, который мне сильно досаждает, связан с отчетам о доставке deliver_sm. В версии протокола 3.4 нет строго определения как должна передаваться статусная информация. С одной стороны есть необязательная структура TLV в которой в жестко типизированной форме передается message_state и сопутствующие параметры. Это вариант хорош, за исключением того, что SMSC не сможет выслать в этой структуре какой-нибудь пространный комментарий. Но, повторюсь, нигде этот способ не указан как обязательный (MUST). Зато в приложении к протоколу приведен пример. Подчеркиваю: ПРИМЕР. Даже не рекомендация. Пример того, как SMSC может сообщать статусную информацию через (о боже, кто это придумал!!!) поле short_message. Т.е. в текстовом виде, странные сокращения, дикие форматы и т.д.
Вообще, это ситуация выбора одного из возможных вариантов (MAY). По моим представления о реализации протоколов выбор одного из разрешенных протоколом варианта — прерогатива формирующей пакет стороны. В данном случае с пакетом отчета это SMSC. А принимающая сторона обязана правильно обработать любой пакет соответствующий протоколу. Но суровая реальность говорит, что прав тот кто платит. Подавляющее большинство SMPP-клиентов понимают только поле short_message.
Славо богу из спецификации пятой версии протокола убрали эту мину (приложение), но найдите-ка SMPP-клиентов пятой версии.
Третий недостаток — передача длинных сообщений. Спецификация ненавязчиво ссылается на стандарт [GSM 03.40] Technical Realisation of the Short Message Service Point to Point». Так ненавязчиво, что замечаешь ссылку только когда ищешь специально. Ссылка на этот стандарт приведена в разделе 1.4 References спецификации версии 3.4.
Вопрос: поле short_message предполагается протоколом использовать только в соответствии с GSM 03.40? GSM 03.40 предлагает длинный текст сообщения разбивается на серию конкатенированных sms, снабженных UDH-заголовками. Спецификация SMPP неявно подстегивает на свободное использование — длина поля 254 октетов. Это две sms латиницей или почти четыре sms кириллицей.
Читаем внимательно спецификацию SMPP:
Т.е. ограничения накладываются передающей сетью (underlying network). В нашем случае underlying network описывается GSM 03.40. Следовательно 140 байт данных. Зачем же такое длинное поле? Дело в том что использоваться может 7-bit кодировка, тогда символов уже 160. short_message это текстовое поле измеряющееся в октетах, а не бинарное в байтах. Возможно, создатели закладывались и на другие, более изощренные варианты.
Разработчик SMPP-клиента по понятным причинам хочет упростить себе задачу. И не стремится на своей стороне связываться c конкатенированными SMS. В соответствии с протоколом SMSC МОЖЕТ предоставлять такую услугу через поле message_payload (самостоятельно делить сообщение на смски, снабжать заголовками ) в форме по своему выбору (не стандартизировано). Но по протоколу не обязан. Да и применять это можно без страха только к обычным текстовым сообщениям. С точки зрения бизнеса вопрос тоже скользкий — как тарифицировать такие сообщения? А что если не все части сообщения имеют статус доставлено?
Четвертые недостаток связан с относительным форматом времени. Относительного чего отмерять указанное время? Когда нет задержек ни на клиенте ни на SMSC и между ними хорошая связь, вопросов, как правило, не возникает. Но если в каком-то месте появляется задержка, то точки отсчета времени клиента и SMSC существенно расходятся.
Для schedule_delivery_time в разделе 5.2.15 уточняется:
Но проблему разных точек отсчета это не решает.
Литература
Первый, самый проблемный недостаток: потеря message_id при разрыве соединения. Страдают от этого операции отправки (submit_sm и т.п.) для которых не успел прийти ответ. Протокол не содержит встроенных средств восстановления утерянных идентификаторов. Как следствие, когда придет статус сообщения, его не к чему привязать. Более того, неизвестно принял ли это сообщение SMSC.
Если обмен осуществляется в синхронном режиме, то потеряется только одно сообщение. Но если работа производится в асинхронном режиме, тогда потери могут быть существенными.
Этот недостаток SMPP, пожалуй, единственный нерешаемый средствами протокола из тех, которые я могу припомнить. Проблема, конечно, решается но не стандартизованными методами.
Остальные недостатки связаны с проблемами реализации. Их решении, как правило, заключается в достижении договоренности между SMSC и SMPP-клиентом и не выходит за рамки спецификации.
Второй недостаток, который мне сильно досаждает, связан с отчетам о доставке deliver_sm. В версии протокола 3.4 нет строго определения как должна передаваться статусная информация. С одной стороны есть необязательная структура TLV в которой в жестко типизированной форме передается message_state и сопутствующие параметры. Это вариант хорош, за исключением того, что SMSC не сможет выслать в этой структуре какой-нибудь пространный комментарий. Но, повторюсь, нигде этот способ не указан как обязательный (MUST). Зато в приложении к протоколу приведен пример. Подчеркиваю: ПРИМЕР. Даже не рекомендация. Пример того, как SMSC может сообщать статусную информацию через (о боже, кто это придумал!!!) поле short_message. Т.е. в текстовом виде, странные сокращения, дикие форматы и т.д.
Вообще, это ситуация выбора одного из возможных вариантов (MAY). По моим представления о реализации протоколов выбор одного из разрешенных протоколом варианта — прерогатива формирующей пакет стороны. В данном случае с пакетом отчета это SMSC. А принимающая сторона обязана правильно обработать любой пакет соответствующий протоколу. Но суровая реальность говорит, что прав тот кто платит. Подавляющее большинство SMPP-клиентов понимают только поле short_message.
Славо богу из спецификации пятой версии протокола убрали эту мину (приложение), но найдите-ка SMPP-клиентов пятой версии.
Третий недостаток — передача длинных сообщений. Спецификация ненавязчиво ссылается на стандарт [GSM 03.40] Technical Realisation of the Short Message Service Point to Point». Так ненавязчиво, что замечаешь ссылку только когда ищешь специально. Ссылка на этот стандарт приведена в разделе 1.4 References спецификации версии 3.4.
Вопрос: поле short_message предполагается протоколом использовать только в соответствии с GSM 03.40? GSM 03.40 предлагает длинный текст сообщения разбивается на серию конкатенированных sms, снабженных UDH-заголовками. Спецификация SMPP неявно подстегивает на свободное использование — длина поля 254 октетов. Это две sms латиницей или почти четыре sms кириллицей.
Читаем внимательно спецификацию SMPP:
4.4.1 “SUBMIT_SM” Syntax
«… Up to 254 octets of short message user data. The exact physical limit for short_message size may vary according to the underlying network… »
Т.е. ограничения накладываются передающей сетью (underlying network). В нашем случае underlying network описывается GSM 03.40. Следовательно 140 байт данных. Зачем же такое длинное поле? Дело в том что использоваться может 7-bit кодировка, тогда символов уже 160. short_message это текстовое поле измеряющееся в октетах, а не бинарное в байтах. Возможно, создатели закладывались и на другие, более изощренные варианты.
Разработчик SMPP-клиента по понятным причинам хочет упростить себе задачу. И не стремится на своей стороне связываться c конкатенированными SMS. В соответствии с протоколом SMSC МОЖЕТ предоставлять такую услугу через поле message_payload (самостоятельно делить сообщение на смски, снабжать заголовками ) в форме по своему выбору (не стандартизировано). Но по протоколу не обязан. Да и применять это можно без страха только к обычным текстовым сообщениям. С точки зрения бизнеса вопрос тоже скользкий — как тарифицировать такие сообщения? А что если не все части сообщения имеют статус доставлено?
Четвертые недостаток связан с относительным форматом времени. Относительного чего отмерять указанное время? Когда нет задержек ни на клиенте ни на SMSC и между ними хорошая связь, вопросов, как правило, не возникает. Но если в каком-то месте появляется задержка, то точки отсчета времени клиента и SMSC существенно расходятся.
Для schedule_delivery_time в разделе 5.2.15 уточняется:
"..relative time from the current SMSC time at which delivery of this message will be attempted by the SMSC.."
Но проблему разных точек отсчета это не решает.
Литература
- Short Message Peer to Peer Protocol Specification v3.4
- [GSM 03.40] Technical Realisation of the Short Message Service Point to Point»