在多用戶聊天中向離線用戶發送郵件（ejabberd）

實際上，我們正在使用ejabberd服務器作爲我們客戶的聊天應用程序之一。除了羣聊之外，一切都運行良好。在多用戶聊天中向離線用戶發送郵件（ejabberd）

我們正在使用MUC進行羣聊，但不會在用戶離線時向成員發送消息。有沒有其他的插件或我們可以使其工作的東西？

或者任何人都可以建議如何從羣聊記錄中爲該用戶接收離線消息。

在此先感謝

2014-03-12 user2609447

@EelLee，其實這個問題一點都不含糊那些誰是相當精通的XMPP規範及其擴展;-) – kostix

[持久XMPP MUC（XEP-45）的可能重複，像WhatsApp組合]（http：// stackoverflow。com/questions/25982426/persistent-xmpp-muc-xep-45-like-whatsapp-groupchats） – Flow

這是因爲沒有這樣的多用戶聊天室的概念。事實上，如果你想想這多一點，你就會明白爲什麼：

參與者的潛在數量的綁定中可能存在的房間在任何給定的時間。

對於哪些用戶目前不存在在MUC房間應該服務器存儲郵件在離線存儲？我的意思是，在一般情況下，服務器不知道所有可能在其託管的指定會議室中聊天的用戶。

（好吧，如果這將是唯一的問題，它可能爲會員專用的房間裏工作，我必須承認。）
MUC房間都沒有「不僅本地服務器」：一個潛在的綁定號碼來自任何數量的其他服務器的用戶都可以加入該會議室，並且通過他們各自的服務器將消息發送給這些用戶。

顯然，這是「MUC空間離線存儲」這種想法沒有意義的另一個原因。
MUC房間的定義是瞬態的：當用戶離線時，他們不在任何房間—（重新）認爲房間是明確的行爲。

這實際上是不支持離線存儲的最重要原因。

正如您所見，XMPP MUC房間非常類似於類固醇IRC聊天室。

所以，你真正想要的是"room history" —的XMPP-0045擴展，它允許客戶端明確要求的房間，他們錯過了消息歷史的一部分。從某種意義上講，不是爲每個用戶存儲離線消息，而是可以將該房間配置爲僅存儲發送給它的一定數量的最新消息（或者在給定的時間段內存儲所有這些消息）。然後房間支持加入的用戶查詢這些消息。

還有另一種可能，您可能會探索："multicast addressing"的XEP-0033（「Extended stanza addressing」）。基本上，它允許客戶端使用特殊的多播服務一次將其消息發送給多個收件人。好處是離線存儲再次存在。缺點是我懷疑ejabberd支持這種多點傳送服務，並且它看起來像擴展留下了很多關於如何實現未指定的細節。

來源

2014-03-12 15:07:00 kostix

感謝Kostix，我已經檢查了多播，它是有道理的。我在想的是將Roster組和Multicast組合起來。我們已經從Android試用過它，並且它正常工作，因爲我們已經收到每個客戶端的離線消息。我發現的唯一問題是在iOS中。有人能指導我嗎？我也想知道我們是否可以發送屬性，或者我們可以定義收到的消息是針對特定組的。 – user2609447

只是爲了更好地瞭解我想要的東西。我們不想在XMPP服務器上存儲任何歷史記錄。我見過的另一個選項是PUBSUB。但沒有任何想法，或者如果有人可以建議我別的東西。 – user2609447

@ user2609447，我不太關注你：離線存儲（當某些目標用戶離線時用於多播）和pubsub將信息存儲在服務器上 - 這是合乎邏輯的，對嗎？ MUC的歷史與這類信息存儲有什麼不同？ – kostix

當我試圖爲我的聊天應用實施羣組聊天時，我遇到了您的問題。我面臨同樣的問題，MUC不爲每個收件人存儲離線消息。而且我不想檢索MUC歷史記錄，這需要用戶重新加入每個MUC來更新其消息數據庫。我想要的是讓服務器保存收件人的離線消息，並讓收件人在上線時獲取所有MUC消息（無需加入每個MUC）。

我所採取的方式是通過發佈訂閱。使用pubsub將強制服務器爲每個收件人存儲離線消息。當用戶重新連接時，他獲取所有離線消息，包括作爲普通消息發送的pubsub消息 - 就是這樣。然而，我與pubub的MUC之間的一個問題是，很難獲得用戶名單。因此，當我的應用程序創建一個羣聊時，它會爲消息創建一個pubsub節點，邀請所有參與者訂閱（包括self）到pubsub，我的應用程序還會創建一個MUC並使每個參與者成爲該MUC的所有者。通過這種方式，可以通過檢查MUC的所有者列表來檢索羣聊參與者的列表。 MUC的唯一目的是保存參與者名單以及小組名稱。其他的一切都由pubsub節點處理。

什麼不清楚的地方，請讓我知道。

其他詳細信息：本質上，當用戶想創建一個羣聊時，我們的應用程序創建一個pubsub節點以及一個MUC。你需要熟悉這兩個概念。對於pubsub節點，您需要設置一個選項以允許任何訂閱者發佈。當用戶發送消息時，他實際上在節點上發佈，ejabberd會將消息發送給所有訂戶，就好像它是常規消息一樣（除了它來自pubsub.yourdomain.com）。因此，如果收件人處於離線狀態，ejabberd會將此郵件存儲爲任何其他常規郵件。

這不是ejabberd如何處理MUC消息。這些只在聊天室中發送給目前的人。然而，郵件的歷史可以由ejabberd存儲，但是爲了讓收件人獲得歷史記錄，他需要加入MUC。這意味着每次應用程序重新連接時，都必須加入所有用戶現有的MUC。我們發現這是不實際的。

我們還使用了MUC爲同一羣組聊天，但是這僅僅是存儲的參與者，使用戶可以得到在任何時候（沒辦法與發佈訂閱做）的列表。

使用發佈 - 訂閱超過MUC的一個額外的好處是，這樣ejabberd存儲發佈訂閱數據方式更加高效。我沒有深入研究這一點，但我期望pubsub的性能更好。在16.09版本

來源

2015-03-10 09:34:06 Georges

因此，似乎你並沒有真正使用MUC，也沒有在pubsub後面加入邏輯。 – DivineDesert

喬治，感謝您的詳細描述！我們公司搜索相同的解決方案以接收來自MUC的所有離線消息。你能否提供一些例子來說明如何配置創建羣聊和pubsub節點的應用程序？ – Murz

嘿喬治請與我們分享，您如何使用pubsub節點獲取羣聊的離線消息。對所有面臨問題的人來說都是有益的。 –

新ejabberd服務器具有多用戶聊天的改進 - MUC子：

MUC小組的目標是試圖依靠儘可能在現有MUC規範，同時使最小使移動組對話客戶端變得容易的可能變化。

該功能默認是啓用的。要使用它，只需確保在要使用它的房間中設置新參數「允許訂閱」。

這裏是鏈接到文件：https://docs.ejabberd.im/developer/proposed-extensions/muc-sub/

此處瞭解詳情：https://blog.process-one.net/xmpp-mobile-groupchat-introducing-muc-subscription/

來源

2016-09-13 12:44:52 Murz

在多用戶聊天中向離線用戶發送郵件（ejabberd）

回答

相關問題