RSS
Собственно, для нас веселье началось когда мы впервые об SMPP услышали. Нам сказали, что мы будем подключаться к МТС, но не сказали как. До этого мы уже посылали SMS через какой-то HTTP шлюз, и поэтому никакой тревоги не было. Позже, однако, выяснилось, что подключение будет по SMPP и тут начались проблемы. Думаю, любой поймет, что есть проблема когда перед тобой PDF спецификация размером в 1М, нет ни одной готовой нормальной реализации и подключение должно быть уже через неделю, не смотря ни на что. Тем более проблемой было, что команда была всего из двух человек и именно я занимался SMPP подключением, а второй товарищ в это время пытался разобраться как именно посылать всякие логотипы и мелодии. Но в итоге все закончилось успешно, не считая потерянных выходных - мы воспользовались Logica SMPP и получился интересный "велосипед на гусеничном ходу". Дело в том, что SMPP канал был написан на Java (с помощью Logica), а сервис отправки логотипов/мелодий - на Python (в тот момент я его уже продвинул в массы). При этом сервис отправки работал через вызов отдельного процесса из SMPP канала (своеобразный CGI для обработки SMS) и все это крутилось на FreeBSD, для которой на тот момент Java была только в бета-состоянии.
В таком состоянии эта система, более-менее, работала около года, не считая того, что у Logica (или Java) были утечки памяти и SMPP канал раз в сутки насильно перезагружался. За это время мы обзавелись уже несколькими подключениями, но в итоге я написал собственную реализацию SMPP на Python для первой SMS олимпиады МТС (не буду сейчас подробно на этом останавливаться, но наверняка расскажу как-нибудь позже). И где-то еще через год я сделал распределенную систему для работы SMS сервисов (и эта тема также заслуживает отдельного рассказа).
А рассказываю я это все к тому, что за все это время (вплоть до текущего момента) мне удалось увидеть поведение целой кучи SMPP реализаций к которым мы подключались. А подключались мы практически ко всем операторам по всей России, странам бывшего СССР и даже некоторым зарубежным операторам. И грустный момент заключается в том, что практически у каждой реализации есть свои проблемы. Вот самые распространенные, или которые мне больше всего запомнились:
- Для большинства ответов в идентификаторе команды должен быть установлен старший бит, но в нескольких реализациях идентификатор команды ответа соответствовал идентификатору команды запроса (т.е. старший бит не был установлен). Получается достаточно смешно, когда в ответ на запрос шлют казалось бы такой же запрос, но тело соответствует ответу. Какое-то время у нас даже был "костыль", который принимал и ответы с неверными идентификаторами основываясь на соответствующем запросе;
- Иногда получается, что клиент вообще говорит с сервером на другом языке. Т.е. посылается один запрос, а ответ (с соответствующим номером) приходит совсем для другого. Скорее всего это связано с частичной реализацией где логика ответов просто жестко "забита".
- Достаточно часто встречается ситуация, когда SMPP соединение не закрывается при закрытии сетевого соединения. Соединение пропало, а повторно его не открыть, т.к. сервер думает, что клиент еще "на линии". В итоге доходило до того, что приходилось звонить, что бы SMPP сессию сбросили вручную.
Исходя из всего этого, я думаю, что SMPP - это самый неверно толкуемый протокол, если учитывать соотношение общего количество реализаций к реализациям без ошибок.
Comments All comments
Comment by bw on 07:14, 2009 3 7
Не слышал о SMPP, любопытно. Мне кажется коллекцию таких протоколов может пополнить и SOAP. Опыт работы с ним, правда, у меня не большой, всего один сервер, да я так и не разобрался, то ли сервер не корректно интерпретирует спецификации, то ли просто под Python нет нормальной реализации, но пришлось добавить кучу костылей, ну и всякое удовольствие от его использования, конечно же, улетучилось.
Хотя, в моём случае, протокол это еще полбеды. На то, как он использовался программистами сервера, смотреть без слез было нельзя, спрашивается, а почему, собственно, не XML-RPC, зачем усложнять жизнь всем. от них и WSDL было не добиться, а примеры использования были не актуальны и оформлены в виде HTTP запросов/ответов :-).
..bw
Comment by goodguy on 11:29, 2009 3 7
SOAP вообще нормально реализуется, если есть грамотное построение интерфейса и понимание требований. Но его беда в том, что в нём предусмотрели кучу всего, вплоть до цифровой подписи и разных возможных модификаций. Но не все библиотеки реализуют этот потенциал и, когда очередному Левше требуется фича, которой нету в используемой им библиотеке, он может даже не обратить внимание, что в стандарте описано как эта фича должна выглядеть и сделать по своему. И после этого остальным приходиться допиливать свои варианты :)
Comment by Dmitry Vasiliev on 18:16, 2009 3 7
> Не слышал о SMPP, любопытно.
Как я понимаю, это де-факто стандарт общения с (и между) SMSC. Но когда мы работали с операторами было меньше проблем, чем сейчас. Сейчас развелось много посредников и если они предоставляют доступ по SMPP, то держись. Тем более, что руководство ищет подешевле. В итоге, мы уже меняем третьего посредника и у двух последних как-раз SMPP - поэтому я и написал эту заметку. :-)
Вторые меня уверяли, что ответ на сообщение о посылке практически постоянно не приходит в течение 2-х минут (!) потому что они ждут его от оператора - я представил, что от них до оператора видимо еще где-то десяток посредников в таком случае :-). Тем более, что этот ответ практически ни к чему не обязывает и обычно приходит в течение нескольких секунд.
Последние (более дешевые), это просто песня. Например, в стандарте есть кодировка UCS2 и я как примерный ее установил и пытался слать в UCS2, но получал при этом кракозябы. При разговоре мне сказали, что не знают как надо (!) и надо попробовать разные варианты. :-) В итоге, оказалось, что надо установить UCS2, а слать в Windows-1251.
> Мне кажется коллекцию таких протоколов может пополнить и SOAP.
SOAP - это, типа, "Ынтерпрайз" и поэтому его пытаются сувать во все дыры. У нас он сейчас тоже как один из серверных протоколов используется и видимо нам до конца придется нести эту ношу. :-(
Comment by Dmitry Vasiliev on 18:25, 2009 3 7
> ...когда очередному Левше требуется фича...
А все потому, что руководство не знает (и, к сожалению, не хочет знать) реальной цены разработки и поэтому один "студент" напишет и потом еще несколько все это дело "костылями" поддерживают. :-) Это, кстати, тема для отдельной заметки.
Comment by goodguy on 19:33, 2009 3 7
Левши это вообще благодатная почва. А в SOAP встретился как-то такой подход, что разработчик создал в протоколе ф-ию Login, которая возвращала некий хэш, который нужно было вставлять в SOAP-header чтобы понять какая сессия идёт. И сессию потом ещё закрывать. Возможно, что это связано с логикой приложения, которое висит за SOAP, но выглядит жутко монструозно при том, что у SOAP есть стандартный подход для цифровых подписей, по которым вполне можно идентифицировать клиентов. Правда для его использования в PHP нужно допилить немного класс, но это делается легко и непринуждённо :)
Comment by Dmitry Vasiliev on 20:43, 2009 3 7
Видимо в области платежных систем есть какое-то негласное правило - если не можешь написать свой, уникальный протокол, то хотя бы исковеркай готовый. :-))
Comment by bw on 21:08, 2009 3 7
> Это, кстати, тема для отдельной заметки.
Это тема для книги, многотомника. Причем это должен быть не справочник или учебник, а некролог высоким технологиям :-).
..bw
Comment by Dmitry Vasiliev on 21:28, 2009 3 7
> Это тема для книги, многотомника.
Абсолютно согласен! :-)) Но я имел в виду, что когда-нибудь соберусь об этом написать с моей точки зрения.
Comment by diesel on 16:45, 2009 4 29
SOAP : попробуйте прогнать примеры запросов из спецификации SOAP 1.1 через xml-валидатор, например w3c-шный...
SMPP : да нормальный протокол, просто все крутят его как хотят. у нас, как ты помнишь, было выражение "есть SMPP, а есть Bercut SMPP". Беркут вообще сказочные пидоры в отношении клиентов и реализованного для операторов софта
Comment by Dmitry Vasiliev on 17:19, 2009 4 29
Про SMPP я именно это и написал, что его неверно толкуют.
Comment by noname on 02:52, 2009 8 16
>Беркут вообще сказочные пидоры в отношении клиентов и >реализованного для операторов софта
Мальчик, ты мудак ? Что имеешь в виду под Bercut SMPP и кто когда-либо тебя заставлял пользовать это для собственных нужд ? Тошно, млять, от таких дебилов.
Comment by Dmitry Vasiliev on 15:51, 2009 8 16
Не ссортесь, горячие финские парни!
Уже много лет назад, нам приходилось работать с теми, кто использовал Bercut SMSC (без понятия как назвать правильно) для собственных нужд. К сожалению, все "изменения" внесенные в SMPP были и нашей проблемой тоже. С учетом того, что на телефон ребята просто не отвечали, у "мальчика" вырвались столь неприятные слова.
На данный момент это все представляет только исторический интерес, так что не стоит больше возвращаться к этой теме.
Comment by Фтещт on 19:18, 2011 6 20
Ответьте, пожалуйста на пару вопросов новичка.
1. Какой смысл взаимодействовать со всеми операторами, когда можно взаимодействовать с каким-то одним (c МТС например), к которому подключены остальные?
2. Берет ли МТС какие-нибудь деньги за использование SMPP-подключения?
3. Накладывает ли МТС какие-то ограничения на объем SMPP-трафика или содержимое сообщений, если да то какие?
Comment by Dmitry Vasiliev on 01:35, 2011 6 22
Я всем этим последний раз занимался лет 6 назад. Сейчас точно нет смысла подключаться напрямую к операторам, только если у вас не грандиозные планы. Сейчас есть множество агрегаторов, которые подключают по SMPP, или HTTP и вам не нужно заботится о куче деталей.
1. Трафик между операторами стоит дополнительных денег и, плюс, короткие номера работают только в рамках одного оператора;
2. Само собой, я думаю деньги не маленькие и скорее всего они не подключают просто так "с улицы"
3. Объем трафика естественно ограничен - в 2003-м звучала цифра 40 SMS/сек для SMSC (т.е. "на всех"). Тогда мы у себя отчетливо наблюдали "полочку" в статистике. Не думаю, что что-то сильно поменялось. Агрегаторы которые работают с рассылками "маринуют" сообщения у себя. Ограничения на контент видимо обычные и скорее всего были прописаны в договоре.
Add comment