Как настроить enquire_link в SMPP и заметить обрыв соединения?

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

Что проверяет enquire_link?

Приложение отправляет шлюзу служебный запрос enquire_link. Шлюз отвечает enquire_link_resp. Такой обмен помогает проверить, что SMPP-сессия ещё отвечает, даже если сейчас бизнес не отправляет SMS. Это особенно полезно для уведомлений о заказах и кодов подтверждения: пауза в отправке здесь не должна скрывать оборванное соединение.

Проверять стоит две стороны обмена. Если шлюз прислал enquire_link вашему приложению, ответьте ему. Если запрос отправило приложение, дождитесь ответа и сопоставьте его с запросом по sequence_number. Иначе ответ на старую проверку легко принять за подтверждение новой.

Ответ enquire_link говорит о состоянии сессии в момент проверки. Он ничего не сообщает о судьбе конкретной SMS. Для неё отдельно отслеживайте ответ на отправку и статус доставки: в материалах smpp.by для этой задачи указан DLR, то есть отчёт о доставке (источник: Smpp).

Как выбрать интервал и тайм-аут без ложных тревог?

Начните с правил вашего шлюза: уточните, как часто он ждёт активность в SMPP-сессии и через какое время закрывает простаивающее соединение. После этого задайте интервал enquire_link короче допустимого простоя. Тайм-аут ответа выбирайте с учётом обычных задержек соединения и требований вашего бизнеса к обнаружению сбоя. Универсальное значение здесь только помешает: слишком короткий тайм-аут вызовет лишние переподключения при краткой задержке.

Зафиксируйте настройки в одном месте вместе с адресом шлюза и параметрами подключения. Тогда при разборе сбоя будет видно, с какими интервалами работала именно эта сессия. Если в приложении открыто несколько соединений, ведите состояние проверки для каждого отдельно: ответ на одном соединении не подтверждает работу соседнего.

Первый рабочий тест прост: отправьте enquire_link через уже открытое соединение и убедитесь, что приложение записало время запроса, время ответа и совпавший sequence_number. Если ответ пришёл, а журнал всё равно показывает тайм-аут, сначала исправьте обработку ответов. Подробный порядок настройки есть в материале о настройке Enquire Link на SMPP-шлюзе.

Что делать, если шлюз перестал отвечать?

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

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

Сценарий восстановления лучше проверить до запуска важных уведомлений. Прервите тестовое соединение во время отправки, затем посмотрите, какие запросы приложение вернуло в очередь и какие оставило на проверку. Разбор неопределённых статусов подробнее описан в материале о тайм-аутах enquire_link без потери сообщений.

Как заметить сбой раньше жалобы клиента?

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

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

После восстановления проверьте скорость разбора очереди. Шлюз может ограничивать поток; в технической документации Devino для ошибки Throttling error описан возврат сообщения в очередь с паузой перед следующей попыткой (источник: Протокол SMPP — Документация Devino Documentation latest). Поэтому шлюз, API-интеграция и аналитика трафика полезны как части одной проверки: видно состояние соединения и то, пошли ли сообщения дальше.

Какие ошибки чаще всего мешают диагностике?

• Проверяют только факт отправки enquire_link. Исправление: записывать ответ и сопоставлять его sequence_number с запросом.
• Считают любой пропущенный ответ доказательством окончательного сбоя. Исправление: сверить тайм-аут с задержками соединения и правилами шлюза.
• Продолжают отправлять SMS через сессию после тайм-аута. Исправление: остановить выдачу новых запросов до проверки или восстановления соединения.
• Повторяют все SMS после переподключения. Исправление: отдельно разобрать запросы, на которые шлюз не успел ответить.
• Следят только за соединением. Исправление: проверять также очередь и статусы доставки, ведь живая сессия ещё не означает, что клиент получил сообщение.

Начните с проверки журнала: найдите последний enquire_link, соответствующий ему enquire_link_resp и их sequence_number. Если такой пары нет, у вас уже есть конкретное место, с которого можно начать настройку контроля соединения.