XMPP：向pubsub添加双向性？

Question

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

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

用例是订阅者平均订阅1000个不同的订阅源，但每个订阅源仅平均每周广播一次信息。所以，很多饲料，但每个饲料的活动都很少。但是，b / c有1000种不同的有效订阅，订阅者可能仍然会收到每天100条消息的通知，并且他们应该能够“回复”又称发布内容到任何一个这样的订阅源。

似乎我需要的是pubsub / multiuserchat混合。但那不存在，或者是吗？任何想法或指针？

非常感谢！

Answer 1

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

至于你关于pubsub与MUC的更一般性的问题，这是我现在发现的一个问题。

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

为帮助确定最适合您的应用程序的内容，让我们来看看两种协议之间的一些差异。

MUC：

1. 绝对适合在线用户互相沟通的标准聊天室。如果这是您正在做的事情，请使用它。
2. 包括在场，即通知其他占用者加入，离开和改变状态。
3. 允许占用者之间进行匿名私密通信。
4. 几乎可以使用任何标准XMPP客户端（标准聊天消息）开箱即用。
5. 当用户离线或断开连接时自动离开房间。
6. 支持具有自定义有效内容的邮件，这意味着您只能使用路由标准聊天消息。

发布订阅：

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

以上几点只是一个指南。通常可以通过服务器配置实现很多。作为示例，MUC规范允许房间基于配置为某些类别的占用者保留在场广播。这里的捕获是在实现中...因为这是MUC的罕见用法，您会发现许多MUC实现可能不支持它。关键是，由于MUC是为聊天而非通用的pubsub而设计的，因此您将在很大程度上找到围绕MUC的所有实现和工具，以专注于这种用法。

Answer 2

不确定问题是什么。订阅者也需要成为发布者。没有什么可以阻止他们发布和订阅（除非节点被配置为禁止它）。

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