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

Question

Я использую клиент mosquitto mqtt.

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

Сценарий 1 (типичный паб/к югу от использования)

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

Сценарий 2

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

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

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

Answer 1

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

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

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

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