Как отличить события публикации MQTT, исходящие от пользователей, от внутренних сообщений, предназначенных только для трансляции

Question

Я использую Mosquitto MQTT клиент.

Например, у вас есть пользователи, которые публикуют и подписываются на темы. Тема фактически соответствует конечной точке REsT.

Сценарий 1 (типичное паб / суб-использование)

1. Пользователь А подписывается на тему / устройство / 123 / meta
2. Пользователь B публикует некоторые данные в теме / устройстве / 123 / meta
   • по определению, эта публикация транслируется подписчикам
   • у нас есть скрипт, подписанный на / devices / #, который знает, как сохранить полезную нагрузку для темы / device / 123 / meta, когда он получает опубликованные данные. Эти данные сохраняются в базе данных.

Сценарий 2

1. Кто-то обновляет данные / устройство / 123 / meta через интерфейс ReST (или путем прямого обновления БД, ключ в том, что это не публикация MQTT).
   • база данных обновлена
   • брокеру MQTT отправляется сообщение публикации, чтобы все подписчики получали обновления в качестве полезной нагрузки.

Сценарий 2 - это то, что я пытаюсь обернуть вокруг. Это создает неприятную петлю обратной связи. Когда внутренние сообщения передаются, мой сценарий для работы с событиями публикации от пользователей не может отличить события публикации от стороннего пользователя от события внутренней публикации, предназначенного только для передачи некоторых данных (без сохранения необходимых данных).

Как мне справиться с этим? Сообщение MQTT очень упрощенное, и я не нахожу ничего, на чем можно было бы основывать логику. Я пытаюсь исследовать, используя происхождение как-то, но безуспешно. Я понимаю, что могу писать плагины, но это довольно сложная задача для комаров.

Answer 1

Невозможно определить, откуда пришло сообщение от абонента на уровне протокола MQTT. Частью протокола pub/sub является разделение издателей от подписчиков.

Самый переносимый способ сделать это - добавить флаг к фактической полезной нагрузке сообщения, чтобы указать, что сообщение было получено не из фактического устройства.

Или предполагая, что сообщение публикуется в результате, триггер в базе данных имеет проверку триггера, действительно ли входящее сообщение изменило сохраненное значение базы данных, если входящие сообщения соответствуют существующему состоянию БД, то нет необходимости переиздавать его.

Механизм плагинов Mosquitto в настоящее время предназначен только для написания решений по аутентификации и авторизации, но брокеры JavaScript mosca или Java HiveMQ поддерживают плагины, которые могут делать то, что вы хотите.