我正在设计一个包含许多设备的系统，使用 MQTT 连接到中央代理。
有些主设备可以向某些从设备发送请求。来自一台主机的请求通常会发送给一台从机。
请求的主题可以是：mysystem/slaveId/req，因此从站可以订阅该主题，并且主站可以发布到同一主题。只有被寻址的从站才会收到请求，正如它应该的那样。
我的问题是如何确定回复主题。我在以下之间有疑问：mysystem/slaveId/res/masterId或者简单地mysystem/slaveId/res.
在第一种情况下，我应该发送masterId到请求负载中的从站，因此从站将能够构造响应主题名称。只有发送请求的主站才会收到答复。
在第二种情况下，所有活跃的 master 都会收到响应，因为该主题不包含masterId。发送请求的主机应该通过查看requestId在有效负载中（也在请求有效负载中发送）。
我认为第一个选择更好，但是设备影子 https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-data-flow.htmlAWS的服务使用类似于第二个选择的主题名称。例如，回复获取请求的设备将消息发布到$aws/things/myLightBulb/shadow/get/accepted。因此，每个设备都会收到该消息，而不仅仅是请求的设备。
我认为 AWS 做出了很好的选择，所以我很想遵循它......但是我不确定我是否理解他们的作用。
“好的选择”取决于上下文，而这里的上下文是不同的。设备影子旨在跟踪并准确反映设备的状态。您链接的页面没有讨论一台设备具有多个阴影，并且可能没有在编写时考虑到多个接收器。尽管如此，它的简单主题架构仍然可以在每个设备有多个影子的系统中工作，因为shadow应收到来自其设备的所有响应。这些响应中的任何一个都可能揭示设备状态的变化，并且客户端未收到响应的任何影子都将过时，并且与其他影子不同步。
你的主人听起来不像影子。也许他们独立地将结果报告给充当影子的数据存储。也许响应中没有任何内容代表除了请求之外值得跟踪的状态变化。不管怎样，该文档听起来与您的目标无关。
我支持您对第一个选择的偏好，尤其是随着节点数量的增长。主要缺点是需要额外的工作来跟踪请求的主 ID。对于大师来说很容易（每个人都可以订阅mySystem/+/res/masterId，并且在具有主题访问控制的系统中，您甚至可以隔离它们）。如果请求正文很简单（还没有要解析的多个属性），您可以考虑让大师发布到mysystem/slaveId/req/masterId（从机可以订阅mysystem/slaveId/req/+).
AWS 的最大例子可能是主题中清晰的层次结构。如果将 masterId 放在主题末尾的解析便利性不是您最关心的问题，那么按如下方式排序可能更有意义：mysystem/masterId/slaveId/req (or res）。非常依赖于您的系统和目标。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
