Мост MQTT с Sparkplug B -> сценарии NDEATH не работают должным образом

avatar
Becker
9 августа 2021 в 01:44
266
1
1

У меня есть две машины, и я тестирую мостовые соединения MQTT с полезными нагрузками Sparkplug B.

У меня есть мосты, работающие должным образом, но когда я имитирую некоторые точки отказа, как указано на изображении ниже, все работает не так, как ожидалось. Я ожидаю, что NDEATH будет виден на брокере на машине B, когда любая из трех точек на изображении отключится.

Когда я убиваю издателя или локального брокера MQTT на машине A, я действительно вижу NDEATH, как и ожидалось, когда подписан на MQTT-брокер на машине B, но когда я отключаю разъем между машинами A и B, как указано в № 3 на изображении я не вижу НЕДЕЙСТВИЯ! Я долго ждал, чтобы убедиться, что у 60-секундной проверки активности было достаточно времени, чтобы среагировать, что, как я понимаю, обычно в 1,5 раза больше, чем обычно.

Публикатор и Брокер на машине А продолжают работать, и когда соединение в точке №3 возвращается в оперативный режим, все сообщения доставляются, но я ожидал, что при отключенном мостовом соединении любые узлы, опубликовавшие последний узел, будут & testament (LWT) увидит NDEATH из-за потери соединения в любой момент.

Я тестировал с mosquitto, vernemq и немного с hive-ce, однако функциональность hive-ce сильно ограничена. Я что-то упустил в моем понимании моста MQTT? Разве NDEATH не следует отправлять во всех трех сценариях?

enter image description here

Источник

Ответы (1)

avatar
Brits
9 августа 2021 в 08:50
2

Из спецификации свечей зажигания:

Критическим аспектом для MQTT в приложении SCADA/IIoT в режиме реального времени является обеспечение того, чтобы основной MQTT SCADA/IIoT Хост-узел может знать «СОСТОЯНИЕ» любого узла EoN в инфраструктуре в течение периода поддержки активности MQTT (см. к разделу 3.1.2.10 спецификации MQTT). Для реализации состояния используется известная Тема Воли и Сообщение Воли. определены и указаны. Тема Воли и Сообщение Воли, зарегистрированные в установлении сеанса MQTT CONNECT, вместе составляют то, что мы называем свидетельством о смерти. Обратите внимание, что вручение Свидетельства о смерти при неожиданном отключении любого клиента MQTT является частью спецификации протокола MQTT, а не частью этого Спецификация Sparkplug™ (обратитесь к разделу 3.1 CONNECT в спецификации MQTT для получения дополнительной информации о том, как Сеанс MQTT установлен и поддерживается).

Итак, в терминах MQTT NDEATH — это «Воля», которая, как упоминалось выше, определена в разделе 3.1 спецификации MQTT:

Если для параметра Will Flag установлено значение 1, это означает, что, если запрос на соединение принят, сообщение Will ДОЛЖНО быть сохранено на сервере и связано с сетевым подключением. Сообщение Will ДОЛЖНО быть опубликовано, когда сетевое соединение впоследствии закрывается, если только сообщение Will не было удалено сервером при получении пакета DISCONNECT

.

Подводя итог, NDEATH создает «Завещание», которое публикует брокер MQTT, если он теряет соединение с издателем (если сначала не получен DISCONNECT).

Когда вы устанавливаете мост, он ретранслирует сообщения, опубликованные в любой теме (темах), для ретрансляции которых настроен мост. Мост передает только опубликованные сообщения; не информация о том, какие клиенты подключены (или какие-либо «Will», которые они могли установить), поэтому, когда мостовое соединение отключится, подписчики не получат NDEATH.

Мониторинг состояния подключения мостов не входит в спецификацию, поэтому параметры варьируются от брокера к брокеру. Например, Mosquitto может (используя 'Will' в мостовом соединении) предоставить уведомление, когда соединение прерывается (см. notifications в mosquitto.conf). Это может предоставить вам несколько вариантов получения необходимой информации.

Becker
9 августа 2021 в 13:10
0

Это имеет смысл, спасибо за четкий ответ и понимание здесь, я видел тему уведомлений по умолчанию, которая может быть полезна, и надеялся, что будет отправлен NDEATH для этой ошибки № 3 после перезапуска локального брокера на машине A генерирует один. Я предположил, что это было сгенерировано удаленным брокером на другой стороне моста, но, возможно, это был локальный брокер, который сделал это как часть отключения, как я видел это на удаленном брокере.