Длительный ремонт шлюза: что останется от MQTT сеанса
Рассмотреть схему крупнее
После ремонта полевой клиент может получить ожидаемые накопленные сообщения, начать новый сеанс либо столкнуться с состоянием старого подключения. Результат зависит от согласованных параметров и реализации. Его нельзя определять по одной фразе «постоянное соединение» в проекте: во время ремонта соединения как раз нет.
Разделить три срока
Укажите ожидаемую длительность отсутствия узла, срок сохранения сеанса и прикладную актуальность сообщений. Эти интервалы решают разные задачи. Даже сохранённый сеанс не делает старое задание подходящим для текущего состояния объекта.
MQTT5 описывает Session Expiry Interval, Clean Start и Message Expiry Interval как отдельные механизмы. (OASIS — MQTT Version 5.0, OASIS Standard) Конкретное поведение проверяют по поддерживаемым версиям и настройкам. Ограничения ресурсов брокера и политика эксплуатации также должны быть известны проекту.
Определить идентичность клиента
Запишите, кто имеет право использовать Client ID и как его получает запасное устройство. Нельзя одновременно запускать старый и заменяющий шлюз с одной идентичностью без предусмотренной архитектуры. Для перехода нужен порядок отключения прежнего экземпляра и подтверждения нового.
Отдельно определите, какие подписки восстанавливаются приложением, а какие ожидаются из сохранённого сеанса. Ответ на подключение и фактическая подписка должны наблюдаться в диагностике. При отсутствии ожидаемого состояния клиент не должен продолжать работу с молчаливым предположением, что всё восстановилось.
Подготовить данные к возвращению
Для накопленных измерений важна исходная временная привязка. Для заданий — допустимость исполнения в новом контексте. Не смешивайте эти классы одной общей очередью без явных правил. Протокольное свойство срока жизни полезно, но прикладная проверка условий всё равно требует собственной спецификации.
На стенде сравните короткий перерыв, отсутствие дольше согласованного срока и замену клиента. Сохраняйте результаты подключения, подписок и получения сообщений. Для каждого сценария сверяйте ожидаемые идентификаторы, а не только число пакетов.
Закрыть ремонт подтверждением
Работа считается восстановленной после появления новых полезных данных и проверки разрешённых входящих сообщений. Старые записи могут догружаться параллельно, если такой режим предусмотрен. Экран должен отличать их от текущих.
В ремонтной карточке укажите, какой сценарий реально произошёл: возобновление или новый сеанс. Если параметры брокера изменялись во время отсутствия узла, приложите соответствующую версию конфигурации. Это поможет объяснить пропавшее состояние без необоснованного вывода, что MQTT обязан хранить любую историю бессрочно и независимо от политики сервиса.
Запросы отправляются на наш e-mail из вашей почтовой программы.
