Когда канал между вашим сервером и SMPP-провайдером рвётся, сообщение может отправиться дважды. Клиент получает дубль — раздражение, бизнес теряет деньги на лишних сообщениях. Разбираем причины и методы защиты.
Основные причины дублирования при сбое канала
Автомастерская в Минске использует SMPP для уведомления клиентов о готовности авто. При кратковременном обрыве интернета мастерская повторно отправила команду «машина готова». Клиент получил два одинаковых SMS, позвонил с претензией. Причина: бизнес не дождался подтверждения от провайдера и отправил повтор по таймауту.
Совет: настройте таймаут ожидания ответа submit_sm_resp на 10–15 секунд и используйте уникальный message_id на стороне отправителя. Если ответ не пришёл, не отправляйте то же сообщение с тем же идентификатором — проверьте статус через query_sm.
Идемпотентность и повторная отправка
Интернет-магазин в Гомеле отправляет уведомления о статусе заказа. После обрыва канала система повторяла команду с тем же sequence_number. Провайдер принял обе команды как разные и отправил два SMS. SMPP-протокол быстрее HTTP-шлюзов, но без правильной логики повторной отправки скорость не спасает от дублей.
Совет: каждое сообщение должно иметь уникальный идентификатор на стороне отправителя (sequence_number или user_message_id). При повторной отправке того же содержимого используйте тот же идентификатор. Провайдер, поддерживающий дедупликацию, не отправит дубль. Уточните у поставщика, работает ли фильтр дублей.
Механизм enquire_link для контроля соединения
Салон красоты в Бресте каждое утро отправляет напоминания о записи. Потеря пакетов на линии приводила к тому, что SMPP-клиент считал соединение живым, хотя провайдер уже разорвал сессию. Сообщения уходили в никуда или дублировались после переподключения.
Совет: настройте enquire_link с интервалом 30–60 секунд. Если ответ не получен, закрывайте сессию и открывайте новую. В новой сессии проверяйте, какие сообщения не получили подтверждения, и отправляйте их заново с тем же уникальным ID.
Тестирование перед запуском SMS-уведомлений через SMPP
Пекарня в Витебске планирует рассылать уведомления о свежей выпечке подписчикам. Запустили без теста — в первый день после временного отключения электричества часть клиентов получила сообщение дважды. Пришлось вручную корректировать базу и извиняться.
Совет: используйте тестовый SMPP-аккаунт провайдера. Симулируйте обрыв канала (выключите сетевой кабель на сервере на 20 секунд) и проверьте, сколько сообщений дошло. Логи должны показать не более одной отправки с одним ID.
Типичные ошибки при настройке защиты от дублей
- Игнорирование параметра registered_delivery — без него вы не получите финальный статус доставки и не поймёте, дошло ли сообщение.
- Использование одного sequence_number для нескольких сообщений — провайдер может принять их за одно.
- Слишком короткий таймаут на ответ submit_sm_resp (менее 5 секунд) — частые ложные срабатывания повторной отправки.
- Отсутствие логирования ошибок — вы не видите, когда и почему происходит дубль.
- Неправильная обработка reconnect: после восстановления соединения некоторые библиотеки автоматически повторяют все неотправленные сообщения без проверки, были ли они уже приняты провайдером.
- Использование стандартных настроек без учёта своего провайдера — у разных операторов разное время ожидания и политика дедупликации.
3 шага, которые можно сделать уже на этой неделе:
- Проверьте логи вашего SMPP-клиента на дубли сообщений за последние 7 дней. Если дубли есть — зафиксируйте точное время и идентификаторы.
- Настройте enquire_link с интервалом 30 секунд и таймаут на ответ submit_sm_resp 15 секунд. Протестируйте на тестовом аккаунте.
- Внедрите уникальный message_id для каждого сообщения на стороне вашей CRM или биллинга. Убедитесь, что при повторной отправке ID не меняется.
Полезные ссылки: SMPP против HTTP-шлюзов: скорость SMS для бизнеса Беларуси, Почему SMS через SMPP надёжнее мессенджеров для уведомлений.