[work] Чужой транспортный протокол как бальзам на душу

Одним из направлений деятельности компании, в которой я работаю, является SMS-агрегирование. Т.е. к нам подключаются клиенты, которые желают отправлять или получать SMS/USSD, а мы подключаемся к целой куче операторов по СНГ и Европе и перекачиваем SMS/USSD-трафик в обе стороны.

Лет 8-10 назад все было просто. Стандартным протоколом для подключения к операторам на просторах бывшего СССР являлся SMPP (Short Message Peer-to-Peer), в Восточной Европе – UCP (Universal Computer Protocol). Имея реализации двух этих протоколов можно было практически безболезненно подключаться чуть ли не ко всем операторам. Грабли, конечно, были. Собственно, за счет этого SMS-агрегаторы и живут, поскольку берут на себя всю головную боль из-за особенностей реализации протоколов тем или иным оператором и прочей организационной лабуды.

Но лет шесть-семь назад началась какая-то ползучая болезнь. Операторы стали ставить у себя разной степени вменяемости и качества промежуточные шлюзы. Сначала это были вариации на тему CPA (Content Provider Access) – т.е. централизованный контроль за тем, что делает поставщик контента – не рассылает ли без спроса спам, к примеру. Некоторые реализации платформ CPA заёбырадовали творческим переосмыслением некоторых моментов протокола SMPP (как, скажем, CPA-платформа от питерской компании “Беркут”). Но они хотя бы давали вход по SMPP.

Потом маразм стал крепчать. Операторы вдруг озаботились внедрением сбацанных на коленке шлюзов для подключения контент-провайдеров. Причем почти все для этих целей выбирали связки из HTTP+XML. Кто-то в чистом виде – HTTP-запрос, на который приходит HTTP-ответ. Кто-то в виде SOAP-а. Один даже использует для этих целей SMTP (т.е. каждый SMS оформляется в виде e-mail, причем без возможности получения отчетов о доставке).

Всему этому пиздбезобразию я находил только одно логическое объяснение: продавцы SMS-центров берут деньги за каждый новый SMPP-вход. Соответственно, хочешь подключать новых провайдеров – плати деньги производителю SMS-центра. Видимо, дешевле подключать провайдеров к самодельному шлюзу, который затем будет работать с SMS-центром по всего одному SMPP-каналу. Впрочем, это только мое предположение, которое может быть сильно ошибочным.

Как бы то ни было, ситуация сейчас напоминает зоопарк с признаками дурдома. Некоторые протоколы, такое впечатление, проектировали очень далекие от предметной области люди. Это касается как собственно технических деталей (громоздкий HTTP+XML транспорт вместо компактного и эффективного бинарного SMPP), так и состава протокола (отсутствие важных полей в сообщениях), так и качества техподдержки – бывает на свои вопросы по непонятным местам протокола приходится выбивать ответы неделями.

В общем, не знаю, добились ли операторы, внедряющие у себя шлюзы с собственными нестандартными протоколами, тех целей, которые они себе ставили. Но SMS-агрегаторы от этого только выиграли. Если раньше потенциальный поставщик контента мог раздобыть реализацию SMPP, сделать подключения к нескольким крупным операторам и спокойно заниматься генерацией контента, то теперь все изменилось. SMPP уже недостаточно. А заниматься реализацией нестандартных протоколов – хлопотно, проще и дешевле подключиться к агрегатору.

Так вот во всем этом ползучем маразме я уже привык к тому, что очередной протокол от потенциального клиента или еще одного оператора будет ничем не лучше остальных – какая-то мутная, донельзя урезанная хрень, да еще и на основе HTTP/XML.

Но сегодня мне попался в руки документ с описанием протокола транспорта SMS от одного серьезного поставщика контента. Это был прямо бальзам на душу. Я этот документ прочитал залпом, как отличную художественную литературу. В нем радует практически все – начиная от формы представления данных (бинарный протокол на принципах TLV) и заканчивая составом и назначением PDU протокола. Все очень близко к тому, до чего мы и сами дошли за все время работы.

Есть еще, оказывается, знающие и толковые люди! Что не может не радовать ;)