Ограничения скорости SMPP: как не потерять транзакционные SMS

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

Почему провайдер ограничивает скорость отправки SMS?

SMPP-шлюз принимает сообщения через команду submit_sm и отвечает результатом обработки запроса. Когда за короткий промежуток приложение отправляет больше сообщений, чем разрешает пропускная способность соединения или маршрута, шлюз возвращает код ошибки throttling. В SMPP его часто обозначают как ESME_RTHROTTLED.

Ограничение защищает очередь шлюза и канал доставки. Оно также помогает провайдеру распределять нагрузку между подключениями. Для бизнеса проблема начинается в тот момент, когда система воспринимает такой ответ как окончательный отказ и просто удаляет SMS из очереди.

Транзакционное сообщение нельзя считать отправленным после вызова API или передачи submit_sm. Сначала нужно получить положительный ответ submit_sm_resp с идентификатором сообщения, затем дождаться DLR, если для сценария нужна подтверждённая доставка. Принципы разбора статусов описаны в материале о настройке SMPP-шлюза для статусов ремонта с DLR.

Как понять, что возник throttling, а не обрыв соединения?

Сначала полезно разделить события по типам. Throttling означает, что соединение живо: шлюз принял запрос, разобрал его и вернул ответ с ограничением. При обрыве соединения приложение не получает SMPP-ответ вовсе либо фиксирует ошибку сети. Эти ситуации требуют разных действий.

• При throttling сообщение остаётся в локальной очереди и ждёт повторной попытки.
• При тайм-ауте нужно проверить состояние SMPP-сессии, журнал запросов и ответов.
• При закрытии сессии приложение открывает новое соединение по правилам переподключения.
• При положительном submit_sm_resp система сохраняет message_id вместе со своим идентификатором заказа, заявки или операции.

Не стоит отправлять одно и то же сообщение повторно сразу после тайм-аута, если неизвестно, успел ли шлюз его принять. Иначе получатель увидит дубликат. Сначала система сверяет журналы, а затем решает, нужно ли повторять отправку.

Как настроить очередь сообщений и скорость отправки?

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

У очереди нужны три простых правила: она хранит порядок задач, знает приоритет сообщения и не удаляет запись до понятного результата. Для каждого сообщения система сохраняет внутренний идентификатор, время постановки в очередь, число попыток, ответ шлюза и message_id после принятия.

Как работает постепенное снижение скорости?

После первого ответа throttling отправляющая система снижает темп передачи и делает паузу перед следующей попыткой. Если ошибки продолжаются, пауза растёт. Когда шлюз снова принимает сообщения без ограничений, скорость повышают постепенно, небольшими шагами. Резкий возврат к прежнему потоку снова создаст всплеск и вернёт ошибку.

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

Что делать с несколькими SMPP-соединениями?

Несколько соединений не означают, что разрешённая скорость автоматически вырастет. Провайдер может учитывать лимит на аккаунт, на подключение или на маршрут. Поэтому перед запуском стоит зафиксировать, какой лимит действует в конкретной схеме, и проверить его на тестовой нагрузке.

Для постоянной сессии обычно выбирают bind_transceiver: через него приложение отправляет сообщения и принимает DLR в одном соединении. Настройки такого подключения разобраны в статье о корректном Bind Transceiver в SMPP v3.4. Если приложение открывает и закрывает сессии на каждый запрос, шлюзу сложнее поддерживать ровный поток, а журналирование становится запутанным.

Какие данные нужны для контроля транзакционных SMS?

Для разбора задержек недостаточно считать количество отправленных запросов. Нужна цепочка событий по каждому сообщению: постановка в очередь, отправка submit_sm, ответ submit_sm_resp, получение DLR либо финальная ошибка. Тогда видно, где именно возникла проблема: внутри приложения, при передаче в шлюз или на последующем этапе доставки.

• Внутренний идентификатор связывает SMS с заказом, заявкой или кодом.
• sequence_number помогает сопоставить submit_sm с ответом submit_sm_resp внутри SMPP-сессии.
• message_id, который вернул шлюз, связывает принятое сообщение с DLR.
• Код статуса показывает, принял ли шлюз запрос или ограничил скорость.
• Время каждого события помогает увидеть очередь и задержку между этапами.

Для аналитики полезно отдельно выводить число throttling-ответов, размер очереди и время ожидания сообщений с высоким приоритетом. Если очередь растёт при стабильном числе ошибок, причина бывает в слишком низкой заданной скорости. Если ошибки появляются рывками, стоит проверить, не запускают ли несколько процессов рассылку одновременно.

Типичные ошибки при настройке throttling

• Считать ESME_RTHROTTLED окончательной ошибкой и удалять сообщение из очереди.
• Повторять запрос без паузы, создавая ещё больше ответов с ограничением.
• Смешивать коды подтверждения и массовую отправку в одной очереди без приоритетов.
• Не сохранять message_id после submit_sm_resp, из-за чего DLR нельзя связать с конкретной операцией.
• Учитывать лимит в каждом сервисе отдельно, хотя все сервисы используют одно SMPP-подключение или один аккаунт.
• Переподключаться при каждом ответе throttling, хотя сессия в этот момент остаётся рабочей.

Как проверить настройку до запуска?

Проверку лучше проводить на отдельном сценарии, который не связан с реальными кодами и уведомлениями клиентов. Система отправляет поток сообщений, фиксирует ответы шлюза, намеренно доходит до ограничения и проверяет четыре вещи: остановилась ли отправка при throttling, сохранились ли сообщения в очереди, снизилась ли скорость и пришли ли DLR по сообщениям, которые шлюз принял.

Отдельно проверьте восстановление после обрыва соединения. Очередь не должна терять задания, а новое подключение должно пройти bind до возобновления отправки. Для контроля живого SMPP-канала применяют enquire_link; порядок настройки описан в инструкции как настроить Enquire Link на SMPP-шлюзе.