MQTT 中推荐的用于私人消息传递的主题结构是什么？答案

【问题标题】：Which is the recommended Topic structure in MQTT for private messaging?MQTT 中推荐的用于私人消息传递的主题结构是什么？
【发布时间】：2017-06-28 04:39:13
【问题描述】：

我正在使用 Eclipse Paho 构建一个基于 MQTT 的私人消息传递应用程序。我是 MQTT 的初学者，所以需要了解主题架构的含义。

如果用户 A 必须向用户 B 发送消息：

让用户 A 订阅主题 A，让用户 B 订阅主题 B。因此，向 B 发送消息的任何人都必须在主题 B 中发布（有效负载包含发件人详细信息）
让用户 A 订阅 A/#，让 B 订阅 B/#。因此 B 向 A 发送消息将发布到主题 A/B

我想知道考虑到其他功能的实现，例如

，私人消息中的推荐主题订阅

最后一次出现
在线
已交付
阅读

请提出实现上述功能的方法（主题、发布和订阅）。例如，在客户端连接到代理后，它将向主题 A/status 发送一条保留消息，其有效负载为“在线”。

【问题讨论】：

推荐私信订阅主题？？？你这是什么意思？
我提供了 2 个选项，其中订阅模式不同于从 A 到 B 获取/发送消息。我需要推荐的订阅模式来进行私人聊天，如 FB Messenger。
你可以定义一个只在 A 和 B 之间知道的奇怪主题，但是你错误地使用了协议......
这听起来很像家庭作业？

标签： chat mqtt publish-subscribe messagebroker

【解决方案1】：

我不会使用 MQTT 这样做，但如果必须，我会使用访问控制列表。 Mosquitto（可能还有其他代理）允许用户拥有发布但不订阅主题的访问权限。这使您可以有效地创建私人消息基础架构，如下所示。

客户端 A 和 B 被授权发布到主题 clientc 但不订阅它。（写但不是读/写访问）

客户端 C 被授权订阅 clientc。（读取权限）

如果客户端 A 向客户端 c 发布消息，则客户端 C 会收到它，但客户端 B 不会。当然，反之亦然。

这种方法有很大的弱点（它假设所有客户端同时在线等），但它是一种可以使用标准 MQTT 代理的私有消息传递结构。然后可以在此之上实现其余功能。此外，您可以通过 PGP 加密消息来进一步加强它。

【讨论】：

【解决方案2】：

第一件事：

MQTT协议中没有私人消息传递，都是基于发布-订阅数据交换机制，如果nodeA想要其他人知道它的消息，然后 nodeA 必须在定义的主题上发布该数据，没有什么可以限制第二个 nodeB 或 nodeC 也可以获取该信息，为什么？ 因为松耦合架构... nodeA 甚至不需要知道谁在获取留言

因此发布数据的节点可以有 0... 或 n 个订阅该主题的用户。

正如我之前所说，Mqtt 是一种协议，其中发布数据的节点不需要知道订阅该节点的任何信息。

在聊天应用程序中正好相反，PartnerA 与 PartnerB 聊天意味着 PartnerA 需要知道如何到达 msgs 的最终（也许是唯一的）目的地...... Mqtt 没有为此定义

【讨论】：

所以 pub-sub 不是用来私聊的吗？虽然 FB Messenger 似乎可以在 MQTT 上进行消息传递
编写您自己的代理，然后您可以使用 MQTT 消息（即 FB Messenger）做任何您想做的事情。
为了扩展这一点：MQTT 只是一个协议，Facebook 编写了他们自己的内部代理，它传递的有效负载（大概）包含允许私人消息传递的进一步路由数据。要创建此功能，您很可能需要做同样的事情。
是的，我想是的，但我不认为 pub-sub 不适合 IM，如 @Φxocę-웃-Пepeúpa-ツ所述。我需要弄清楚要记住的事情。我想互联网上没有太多关于这方面的信息。
HiveMQ 能够支持访问控制列表 (ACL)。另外，我相信有支持 ACL 的 Mosquitto 插件。如果您正在构建一个 IM 应用程序，那么在几个用户之后，处理 ACL 将变得非常麻烦。我想您可以将 /MyIM/Private/User/{username}/ 作为主题并制作 ACL，以便每个人（“世界”）都可以发布到它，并且只允许匹配的用户名订阅它。但 ACL 的管理工作量很大。