Надёжная интеграция SMPP — это вопрос операционной дисциплины, а не только корректных PDU: выберите правильный режим bind, аккуратно управляйте sequence_number и окном, повторяйте с экспоненциальной выдержкой и джиттером, делайте отправку идемпотентной во избежание двойной тарификации, подтверждайте каждый deliver_sm и корректно переподключайтесь при сбое. Сделайте это правильно — и детали протокола позаботятся о себе сами.
bind_transceiverОткрыть и аутентифицировать сессиюbind_transceiver_respСессия принятаsubmit_smОтправить сообщениеsubmit_sm_respПринято, возвращен ID сообщенияdeliver_smПодтверждение доставки или входящее сообщениеdeliver_sm_respПодтвержденоenquire_linkKeepalive в режиме ожидания
Стратегия bind
Предпочитайте bind типа transceiver, где провайдер это допускает, чтобы одно соединение несло и отправку, и приём и упрощало корреляцию DLR. Согласуйте число одновременных bind и TPS на каждый bind с провайдером письменно перед масштабированием. Подтверждайте согласованную версию SMPP из bind_resp и обрабатывайте сбои bind явно — повторяйте временные состояния типа ESME_RALYBND, но воспринимайте ESME_RINVPASWD/ESME_RINVSYSID как фатальные ошибки конфигурации, а не зацикливайтесь.
sequence_number и окно
Присваивайте монотонно возрастающий sequence_number (от 1 до 0x7FFFFFFF, затем циклически) и используйте его для корреляции каждого ответа с его запросом. Отслеживайте незавершённые запросы в отображении с ключом sequence_number и тайм-аутом, чтобы обнаруживать так и не пришедший ответ. Соблюдайте окно: ограничивайте число неподтверждённых PDU в полёте и приостанавливайте отправку, когда оно заполнено, а не отправляйте вслепую, что вызывает троттлинг.
| Состояние | Почему |
|---|---|
| Карта незавершенных запросов (по sequence_number) | Сопоставляйте ответы, выявляйте тайм-ауты |
| Счётчик заполненности окна | Обратное давление перед ESME_RTHROTTLED |
| Ключ идемпотентности для каждого логического сообщения | Предотвратить повторную отправку при повторной попытке |
| Состояние bind + время последнего enquire_link_resp | Обнаружение неактивных сессий |
Повторы, выдержка и идемпотентность
Повторяйте временные сбои (ESME_RMSGQFUL, ESME_RTHROTTLED, системные ошибки, тайм-ауты) с экспоненциальной выдержкой и джиттером, чтобы шторма переподключений не синхронизировались между рабочими процессами. Не повторяйте постоянные ошибки (неверный адрес, неверный пароль). Главное — делайте отправку идемпотентной: прикрепляйте собственную ссылку (например, через user_message_reference) и устраняйте дубликаты, чтобы повтор после неоднозначного тайм-аута не приводил к двойной тарификации или двойной доставке.
Обработка отчётов о доставке
Запрашивайте registered_delivery только там, где вы обрабатываете отчёты. Всегда отвечайте deliver_sm_resp оперативно, а обработку выполняйте асинхронно. Корреляцию отчётов выполняйте по TLV receipted_message_id, нормализуя шестнадцатеричный/десятичный форматы идентификатора, и закрывайте сообщение только по конечному stat. Сопоставляйте сетевые коды err с нормализованной таксономией, чтобы качество было сопоставимо между маршрутами. Отличайте промежуточные уведомления от конечных состояний.
Keepalive и переподключение
Отправляйте enquire_link по таймеру простоя и воспринимайте пропущенный ответ как признак мёртвой сессии. При любом разрыве переподключайтесь с выдержкой и джиттером, а не зацикливайтесь. При переподключении возобновляйте из чистого состояния: выполните bind заново, сбросьте отображение незавершённых запросов и полагайтесь на идемпотентность для безопасной повторной отправки всего, что было в полёте. Отслеживайте состояние bind, заполнение окна, задержку отправки/DLR и долю кодов ошибок и настройте оповещения на всё это.
Часто задаваемые вопросы
Как присваивать sequence_number?
Используйте монотонно возрастающий счётчик от 1 до 0x7FFFFFFF, затем циклически. Держите отображение незавершённых sequence_number с тайм-аутами, чтобы коррелировать каждый ответ и обнаруживать запросы, так и не получившие ответа.
Как избежать двойной тарификации при повторах?
Делайте отправку идемпотентной. Прикрепляйте собственную ссылку (например, user_message_reference), устраняйте дубликаты по ней и проектируйте повторы так, чтобы повторная отправка после неоднозначного тайм-аута распознавалась и подавлялась, а не доставлялась и тарифицировалась дважды.
Какие ошибки SMPP следует повторять?
Повторяйте временные — ESME_RMSGQFUL, ESME_RTHROTTLED, системные ошибки и тайм-ауты — с экспоненциальной выдержкой и джиттером. Не повторяйте постоянные ошибки, такие как ESME_RINVDSTADR или ESME_RINVPASWD; вместо этого исправьте входные данные или конфигурацию.
Что отслеживать на bind SMPP?
Состояние bind, время с последнего enquire_link_resp, заполнение окна, задержку отправки и DLR и долю ошибок по кодам (особенно ESME_RTHROTTLED). Настройте оповещения на рост троттлинга или застопорившееся окно как ранние сигналы проблем.
Как обрабатывать переподключение после разрыва сессии?
Переподключайтесь с экспоненциальной выдержкой и джиттером, выполните bind заново, сбросьте отображение незавершённых запросов и повторно отправьте сообщения в полёте, полагаясь на идемпотентность для предотвращения дубликатов. Никогда не зацикливайте переподключения — это может привести к блокировке вашего IP.
Технические характеристики источника
На этой странице представлены опубликованные стандарты, на которых они основаны. (Открывается в новой вкладке)