XMPP:向 pubsub 添加双向性？

Question

我不确定 pubsub 或 multiuserchat 是否可行？

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

用例是这样的，订阅者将平均订阅 1000 个不同的订阅源，但每个单独的订阅源平均每周只广播一次信息。所以，有很多提要，但每个提要的事件量都很低。但是，b/c 有 1000 个不同的事件订阅，订阅者可能仍会每天收到 100 条消息的通知，并且他们应该能够“回复”也就是将内容发布到这些提要中的任何一个。

看来我需要的是 pubsub/multiuserchat 混合。但这不存在，或者是吗？任何想法或指示？

非常感谢!

Answer 1

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

至于您关于 pubsub 与 MUC 的更一般的问题，这是我发现现在经常出现的问题。

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

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

穆克:

绝对适合在线用户相互交流的标准聊天室。如果这是您正在做的事情，请使用它。

包括在场，即通知其他居住者加入、离开和改变状态。

允许居住者之间的匿名私有(private)通信。

开箱即用，几乎可以与任何标准 XMPP 客户端(用于标准聊天消息)一起使用。

当用户离线或断开连接时自动离开房间。

支持具有自定义负载的消息，这意味着您只能路由标准聊天消息。

发布者:

一个或几个发布者传输给许多只读订阅者是核心发布订阅领域。与 MUC 相比，订阅者不发布，也不接收其他订阅者的信息。

服务器实现往往对 pubsub 有更灵活的访问控制。

仅自定义有效负载，没有标准聊天消息。

可选择具有完整的项目持久性。

可以将节点作为项目列表进行管理(即，通过通知添加/删除)，而不仅仅是简单的广播。

订阅可以通过离线保持。

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