XMPP：向 pubsub 添加双向性？

Question

我不确定 pubsub 或多用户聊天是否是正确的选择？

我认为我需要的是 pubsub，但还需要订阅者能够向 feed 广播消息。双向信息流，如果你愿意的话。

用例是订阅者平均订阅 1000 个不同的 feed，但每个单独的 feed 平均每周仅广播一次信息。因此，提要很多，但每个提要的活动都很低。然而，由于有 1000 个不同的活动订阅，订阅者每天可能仍会收到 100 条消息的通知，并且他们应该能够“回复”（即发布内容）到这些提要中的任何一个。

看来我需要的是一个 pubsub/多用户聊天混合体。但这并不存在，或者真的存在吗？有什么想法或指示吗？

非常感谢！

Answer 1

如果订阅者正在发布数据，那么他们不仅仅是订阅者，而且是发布者。同一实体没有理由不能同时成为发布者和订阅者。

至于你关于 pubsub 与 MUC 的更普遍的问题，我发现这个问题现在经常出现。

显然乍一看MUC和pubsub非常相似，它们都是关于向一个组广播的。许多应用程序可以轻松地使用其中之一，没有任何问题。

为了帮助确定哪种协议最适合您的应用程序，让我们了解一下这两种协议之间的一些差异。

MUC：

1. 对于在线用户相互交流的标准聊天室来说绝对有好处。如果这就是您正在做的事情，请使用它。
2. 包括存在，即通知其他居住者加入、离开和改变状态。
3. 允许居住者之间进行匿名私人通信。
4. 几乎可以与任何标准 XMPP 客户端（用于标准聊天消息）一起使用。
5. 当用户离线或断开连接时自动离开房间。
6. 支持具有自定义负载的消息，这意味着您只能路由标准聊天消息。

Pubsub：

1. 一个或几个发布者向许多只读订阅者传输内容是核心 pubsub 领域。与 MUC 相比，订阅者不会发布信息，也不会接收有关其他订阅者的信息。
2. 服务器实现往往对 pubsub 具有更灵活的访问控制。
3. 仅自定义有效负载，没有标准聊天消息。
4. 可选择具有完整的项目持久性。
5. 节点可以作为项目列表进行管理（即添加/删除通知），而不仅仅是简单的广播。
6. 订阅可以在离线状态下持续存在。

以上几点仅供参考。通常可以通过服务器配置来实现很多目标。例如，MUC 规范允许房间根据配置拒绝某些类别的占用者的存在广播。这里的问题在于实现......因为这是 MUC 的不常见用法，您会发现许多 MUC 实现可能不支持它。重点是，由于 MUC 是为聊天而不是通用的 pubsub 设计的，因此您会在很大程度上发现围绕 MUC 的所有实现和工具都专注于这种用法。

Answer 2

不确定问题是什么。订阅者也只需是发布者即可。没有什么可以阻止他们发布和订阅（除非节点配置为禁止这样做）。

这似乎是一个非常典型的 pubsub 案例。