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. 一個或幾個出版商傳送到許多隻讀用戶爲核心的發佈訂閱領土。與MUC相反，用戶未發佈，並且未收到有關其他用戶的信息。
2. 服務器實現往往對pubsub具有更靈活的訪問控制。
3. 只有自定義有效載荷，沒有標準的聊天消息。
4. 可選具有完整的項目持久性。
5. 節點可以作爲項目列表進行管理（即添加/刪除通知），而不僅僅是簡單的廣播。
6. 訂閱可以保持通過脫機。

以上幾點僅供參考。通常可以通過服務器配置來實現。例如，MUC規範允許房間根據配置爲特定類別的居住者預扣廣播。這裏的實現是在實現中...因爲這是MUC的一種不常見的用法，您會發現它在許多MUC實現中可能不被支持。重要的是，因爲MUC是專爲聊天而不是通用pubsub的，所以你將會在很大程度上找到MUC的所有實現和工具來專注於這種用法。

Answer 2

不知道是什麼問題。訂閱者也需要成爲發佈者。沒有什麼能夠阻止他們發佈以及訂閱（除非節點被配置爲禁止它）。

這似乎是一個非常典型的pubsub案例。