XMPP：向pubsub添加双向性？

我不确定pubsub或multiuserchat是一种方式

我想我需要的是pubsub，但它还增加了订阅者向提要广播消息的功能。双向信息流，如果你愿意的话

用例是这样的，订阅者将平均订阅1000个不同的提要，但每个提要平均每周只广播一次信息。所以，有很多饲料，但每种饲料的活性都很低。然而，b/c有1000个不同的活动订阅，订阅者每天可能会收到100条消息的通知，并且他们应该能够“回复”这些订阅源中的任何一条

看起来我需要的是一个pubsub/multiuserchat的混合版本。但那是不存在的，还是真的？有什么想法或建议吗

---

非常感谢

不确定是什么问题。订阅者也需要是发布者。没有任何东西可以阻止它们发布和订阅（除非节点配置为不允许）

---

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

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

至于你关于pubsub和MUC的更一般的问题，我发现这个问题现在经常出现

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

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

MUC：

对于在线用户的标准聊天室来说，这绝对是一个不错的选择。如果这是你正在做的，就用它

包括在场，即通知其他乘员加入、离开和改变状态

允许居住者之间进行匿名私人通信

适用于几乎任何标准的XMPP客户端（用于标准聊天消息）

当用户脱机或断开连接时自动离开房间

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

Pubsub:

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

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

仅限自定义有效负载，无标准聊天信息

（可选）具有完整的项目持久性

一个节点可以作为一个项目列表来管理（即添加/删除通知），而不仅仅是简单的广播

订阅可以通过脱机方式保持

---

以上几点只是一个指南。通常，通过服务器配置可以实现很多功能。例如，MUC规范允许根据配置为特定类别的乘客保留状态广播。这里的关键在于实现。。。由于这是MUC的一种不常见用法，您会发现在许多MUC实现中可能不支持它。关键是，由于MUC是为聊天而设计的，而不是一般的pubsub，因此您会发现MUC的所有实现和工具都将重点放在这种用法上。

Hi Robin and@MattJ，您能告诉我如何允许每个订阅者也成为发布者吗？我正在阅读pubsub标准的文档，但还不太清楚。如果一个节点已经存在，并且有一个新用户订阅了，那么需要发送什么IQ或config选项才能获得发布权限？我错过了这个评论。如果您真的希望每个订阅者都能够发布，那么理想情况下，您可以将其指定给您的pubsub服务，让每个JID都能够发布。请参阅XEP关于从属关系的部分[1]，如果您想通过XMPP控制它们，请管理它们[2]。[1]: [2]: