Как настроить Enquire Link на SMPP-шлюзе

Enquire Link поддерживает контроль соединения между вашим SMPP-клиентом и SMSC. Если шлюз отправляет этот запрос через согласованный интервал, а система отвечает Enquire Link Response, обе стороны видят, что TCP-сессия жива. В статье разберём, как выбрать интервал, настроить таймаут, отличить потерю связи от ошибки отправки и проверить результат по логам. Эти шаги подходят небольшому бизнесу, который передаёт SMS через собственное приложение или промежуточную платформу.

Что делает Enquire Link в соединении SMPP?

После установки SMPP-сессии приложение и SMSC обмениваются командами поверх TCP. Когда в канале есть обычный трафик, состояние соединения видно по SubmitSM, SubmitSMResp и другим пакетам. Но если сообщений некоторое время нет, одна сторона может не узнать о разрыве сразу. TCP-соединение иногда выглядит открытым, хотя удалённый сервер уже недоступен.

Enquire Link решает эту задачу контрольным запросом. SMPP-клиент отправляет PDU enquire_link, SMSC возвращает enquire_link_resp. В ответе должен совпадать sequence_number исходного запроса. Это позволяет связать запрос с конкретным ответом и измерить задержку.

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

Как выбрать интервал Enquire Link?

Интервал задают между отправками контрольных запросов, когда соединение не получает другой трафик. Его нельзя выбирать отдельно от таймаута ответа и политики SMSC. Сначала запросите у поставщика SMPP параметры keep-alive: допустимую частоту, время ожидания ответа и требования к повторному подключению.

Практическая схема выглядит так:

1. Запустите таймер после успешного подключения и авторизации в SMPP.
2. Сбрасывайте таймер при любом входящем или исходящем PDU, если шлюз считает обычный трафик признаком активности.
3. Отправляйте enquire_link, когда канал простаивает дольше заданного интервала.
4. Записывайте время отправки и номер последовательности.
5. После enquire_link_resp фиксируйте задержку и снова запускайте отсчёт.

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

Если в приложении уже есть отдельный TCP keep-alive, не считайте его полной заменой SMPP-команды. TCP проверяет состояние сетевого соединения на своём уровне, а Enquire Link подтверждает, что удалённая сторона отвечает как SMPP-система.

Как настроить таймаут ответа и переподключение?

Таймаут Enquire Link начинается после отправки PDU. Он должен быть меньше периода, после которого бизнес считает канал потерянным, но достаточно длинным для реальной задержки сети и обработки на стороне SMSC. Один пропущенный пакет ещё не всегда означает окончательный сбой: сеть могла потерять пакет, а сервер мог кратковременно задержать ответ.

Поэтому в коде разделите три события:

• ответ получен — сессия остаётся активной;
• таймаут одного запроса — событие попадает в журнал, счётчик пропусков увеличивается;
• порог пропусков достигнут — приложение закрывает старый сокет и начинает новый bind.

При переподключении сначала остановите таймеры старой сессии. Иначе старый поток может отправить Enquire Link уже в закрытый сокет или обработать ответ от другой сессии. Затем корректно закройте соединение, создайте новый TCP-сеанс, выполните bind и только после успешной авторизации включите keep-alive.

Повторное подключение не должно запускаться бесконечно без паузы. Используйте возрастающую задержку между попытками и записывайте причину каждой попытки: таймаут, закрытие TCP, отказ bind или ошибка протокола. Такая запись помогает отделить проблему сети от неверных учётных данных.

После восстановления сессии проверьте очередь исходящих сообщений. Нельзя автоматически считать каждое SMS из старой очереди доставленным только потому, что новый bind прошёл успешно. Статусы SubmitSM и DLR обрабатывайте по своим правилам. Для разбора подтверждений доставки пригодится материал о SMPP-статусах и чтении DLR.

Какие пакеты нужно видеть в логах?

Минимальный лог для диагностики хранит направление пакета, команду, sequence number, время отправки и время ответа. Текст SMS и другие чувствительные поля для проверки keep-alive не нужны. По журналу должно быть понятно, какая команда ушла последней и когда приложение решило считать соединение недоступным.

Полезно отдельно считать время между запросом и ответом. Редкие пики покажут сетевые задержки, а одинаковые таймауты после простоя укажут на закрытие неактивных соединений. Если Enquire Link отвечает, но SubmitSM возвращает ошибки, проблема находится уже в параметрах отправки, маршрутизации или лимитах, а не в keep-alive.

Какие ошибки встречаются при настройке?

• Один общий таймер на все соединения. Если приложение держит несколько SMPP-сессий, каждая должна иметь собственное состояние и свой sequence number.
• Проверка только TCP-сокета. Открытый сокет не подтверждает, что SMSC отвечает на SMPP-команды.
• Игнорирование sequence number. Ответ нельзя принимать как подтверждение запроса, если его номер не совпадает.
• Отправка Enquire Link во время остановки. При завершении процесса сначала выключайте таймер, затем закрывайте соединение.
• Мгновенное переподключение после любого сбоя. Такая логика создаёт поток новых соединений и усложняет диагностику.
• Отсутствие наблюдения за DLR. Живой keep-alive подтверждает канал, но не доставку конкретного SMS.

Для малого проекта настройку лучше проверять на тестовом трафике: сначала убедиться, что bind проходит, затем искусственно разорвать TCP-соединение и посмотреть, как приложение обнаружит сбой. После этого проверьте восстановление очереди и соответствие статусов. Если бизнес переходит с HTTP API на постоянное SMPP-соединение, заранее составьте отдельный сценарий миграции, чтобы не смешать проблемы keep-alive с изменением формата отправки. Практический разбор есть в материале о миграции с HTTP API на SMPP без потери SMS.