请求/响应的MQTT主题名称 [英] MQTT topic names for request/response

问题描述

我正在设计一个包含许多使用MQTT连接到中央代理的设备的系统.

I'm designing a system with many devices using MQTT to connect to a central broker.

有些主服务器可以将请求发送到某些作为从设备的设备.来自一个主机的请求通常被定向到一个从机.

There are some masters that can send requests to certain devices that are slaves. The request from one master is usually directed to one slave.

请求的主题可以是:mysystem/slaveId/req，因此从服务器可以订阅该主题，而主服务器可以发布到同一主题.

The topic for requests could be: mysystem/slaveId/req, so the slaves can subscribe to this topic and master publishes to the same topic. Only the addressed slave will receive the request, as it should be.

我的问题是如何确定答复主题.我对此感到怀疑:mysystem/slaveId/res/masterId或只是mysystem/slaveId/res.

My question is how to decide the topic for responses. I'm in doubt between: mysystem/slaveId/res/masterId or simply mysystem/slaveId/res.

在第一种情况下，我应该在请求的有效负载中将masterId发送到从属服务器，以便从属服务器能够构造响应主题名称.答案将仅由发送请求的主机接收.

In the first case, I should send masterId to the slave in the payload of request, so the slave will be able to construct the response topic name. The answer will be received only by the master that send the request.

在第二种情况下，所有活动主控都将收到响应，因为该主题不包含masterId.发送请求的主机应通过查看有效负载中的requestId(也已在请求有效负载中发送)来检测其响应.

In the second case, all the active masters will receive the response, because the topic doesn't contain the masterId. The master that send the request should detect its response by looking at a requestId in the payload (that was sent in the request payload too).

我认为首选是更好的选择，但是

I think the first choice is better, however the Device Shadow service of AWS uses topic names similar to the second choice. For example the device that replies to a get request publishes a message to $aws/things/myLightBulb/shadow/get/accepted. So every devices will receive the message, not only the one that requested.

我认为AWS做出了不错的选择，因此我很想遵循它……但是我不确定我是否了解它们的作用.

I think AWS makes good choices, so I am tempted to follow it... however I'm not sure if I understood what they do.

推荐答案

好的选择"取决于上下文，这里的上下文有所不同.设备阴影旨在跟踪并准确反映设备状态.您链接的页面没有讨论在一个设备上存在多个阴影，并且在编写时可能没有考虑多个接收者.尽管如此，其简单的主题体系结构仍可在每个设备具有多个阴影的系统中工作，因为 shadow 应该会收到其设备的所有响应.这些响应中的任何一个都可能揭示设备状态的变化，并且客户端未收到响应的任何影子都将过时，并且与其他影子不同步.

"Good choices" depend on context, and here the contexts differ. A Device Shadow is meant to track and accurately reflect the state of the device. The page you linked does not discuss having multiple shadows for one device, and may not have been written with multiple receivers in mind. Still, its simple topic architecture would work in a system that had multiple shadows per device because a shadow should receive all responses from its device. Any of those responses could reveal a change in device state, and any shadow whose client does not receive the response will be out of date, and out of sync with the other shadows.

您的母带听起来不像是影子.也许他们独立地将结果报告给充当影子的数据存储.响应中可能没有任何内容表示状态变化值得跟踪超出请求的范围.无论哪种方式，文档听起来都不符合您的目标.

Your masters do not sound like shadows. Perhaps they independently report their results to a data store that functions as the shadow. Perhaps nothing in the responses represents a state change worth tracking beyond the request. Either way, the documentation does not sound relevant to your goal.

我支持您首选的偏爱，尤其是随着节点数量的增长.主要缺点是需要额外的工作来跟踪请求的主ID.对于主人来说很容易(每个人都可以订阅mySystem/+/res/masterId，并且在具有主题访问控制的系统中，您甚至可以隔离他们).如果请求主体很简单(尚不可以解析多个属性)，则可以考虑将主服务器发布到mysystem/slaveId/req/masterId(从服务器可以预订mysystem/slaveId/req/+).

I support your preference for the first choice, especially as the number of nodes grows. The main drawback is the extra work keeping track of the requesting master ID. It's easy for the masters (each can just subscribe to mySystem/+/res/masterId, and in a system with topic access control you could even isolate them). If the request body is otherwise simple (not already multiple attributes to parse), you might consider having the masters post to mysystem/slaveId/req/masterId (slave could subscribe to mysystem/slaveId/req/+).

从AWS上获取的最大示例可能是主题中清晰的层次感.如果您最关心的不是在主题末尾使用masterId的解析方便性，则按以下顺序进行排序可能更有意义:mysystem/masterId/slaveId/req(或res).非常取决于您的系统和目标.

The biggest example to take from AWS might be the clear sense of hierarchy in the topics. If the parsing convenience of having the masterId at the end of the topic is not your top concern, it might make more sense to order as: mysystem/masterId/slaveId/req (or res). Very dependent on your system and goals.

这篇关于请求/响应的MQTT主题名称的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！