如何区分源自用户的MQTT发布事件与仅广播的内部消息之间的区别 [英] How do I differentiate between MQTT Publish events originating from Users vs internal messages meant to broadcast only

问题描述

我正在使用mosquitto mqtt客户端.

I am using mosquitto mqtt client.

例如，您有发布和订阅主题的用户.该主题实际上与REsT端点相关.

For example, you have users that publish and subscribe to topics. The topic actually correlates to a REsT endpoint.

方案1(典型的发布/订阅使用情况)

1. UserA订阅主题/device/123/meta
2. UserB将一些数据发布到主题/device/123/meta
   • 根据定义，此发布会广播给订阅者
   • 我们有一个订阅到/devices/#的脚本，该脚本知道如何在主题/device/123/meta收到发布的数据时保存其有效负载.此数据将保存到数据库.

1. UserA subscribes to topic /device/123/meta
2. UserB publishes some data to topic /device/123/meta
   • by definition, this publish is broadcasted out to the subscribers
   • we have a script subscribed to /devices/# which knows how to save the payload for the topic /device/123/meta when it receives publish'ed data. This data is saved to the database.

场景2

1. 有人通过ReST接口(或直接数据库更新，关键是它不是MQTT发布)更新数据/device/123/meta.
   • 数据库已更新
   • 将发布消息发送到MQTT代理，以便所有订阅者都将更新作为有效负载获取

1. Someone updates data /device/123/meta via a ReST interface (or a direct DB update, the key is it's not a MQTT publish).
   • database is updated
   • a publish message is sent to the MQTT broker so that all subscribers get the updates as a payload

方案2是我想要解决的问题.这会造成讨厌的反馈循环.当内部消息被广播出去时，我处理用户发布事件的脚本无法区分源自第三方用户的发布事件还是仅用于广播某些数据的内部发布事件(无需保存数据).

Scenario 2 is what I'm trying to wrap my head around. This creates a nasty feedback loop. When internal messages are broadcasted out, my script to deal with publish events from users can't differentiate between publish events originating from a 3rd party user or an internal publish event only meant to broadcast out some data (with no saving of data needed).

该如何处理? MQTT消息非常简单，我找不到可以作为逻辑基础的任何东西.我正在尝试探索以某种方式使用起源，但到目前为止还没有运气.我意识到我可以编写插件，但这对mosquitto来说是相当艰巨的任务.

How should I handle this? The MQTT message is very simplistic and I'm not finding anything I can base logic off of. I'm trying to explore using the origin somehow, but no luck this far. I realize I can write plugins, but this is quite the task for mosquitto.

推荐答案

在纯MQTT协议级别上，无法区分消息源自订阅者的位置.发布/订阅协议的部分要点是使发布者与订阅者脱钩.

There is no way to distinguish where a message originated from the subscriber at a pure MQTT protocol level. Part of the point of a pub/sub protocol is to decouple publishers from subscribers.

最可移植的方法是在实际消息有效负载中添加一个标志，以指示该消息源自实际设备以外的其他地方.

The most portable way to do this would be to add a flag to the actual message payload to indicate that message originated from somewhere other than the actual device.

或者假设消息的发布结果是数据库中的触发器，则触发器将检查传入消息是否确实更改了数据库的存储值，如果传入消息与数据库的现有状态匹配，则无需重新发布.

Or assuming the message is being published as a result a trigger in the database have the trigger check if the incoming message actually changed the database stored value, if the incoming messages matches the existing state of the DB then there is no need to republish it.

Mosquitto的插件机制当前仅用于编写身份验证和授权解决方案，但是JavaScript mosca 或Java <一个href ="http://www.hivemq.com/" rel ="nofollow"> HiveMQ 经纪人支持可以执行您想要的功能的插件.

Mosquitto's plugin mechanism is currently only for writing authentication and authorisation solutions, but the JavaScript mosca or Java HiveMQ brokers support plugins that may be able to do what you want.

这篇关于如何区分源自用户的MQTT发布事件与仅广播的内部消息之间的区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！