Tatsächlich verwenden wir den ejabberd-Server für eine der Chat-Anwendungen unseres Kunden. Alles funktioniert gut außer Gruppen-Chat.
Wir verwenden MUC für den Gruppenchat, aber es sendet keine Nachrichten an das Mitglied, wenn die Verwendung offline ist. Gibt es ein alternatives Plugin oder etwas, wo wir das machen können?
Oder jemand kann vorschlagen, wie man Offline-Nachrichten für diesen Benutzer aus dem Gruppen-Chat-Verlauf erhält.
Vielen Dank im Voraus
Das liegt daran, dass es kein solches Konzept für Multi-User-Chaträume gibt. In der Tat, wenn Sie darüber ein wenig mehr nachdenken, werden Sie verstehen warum:
Eine potenziell ungebundene Anzahl von Teilnehmern kann zu einem bestimmten Zeitpunkt in einem Raum anwesend sein.
Also genau für welche Benutzer nicht gegenwärtig im MUC-Raum sollte der Server die Nachrichten im Offline-Speicher speichern? Ich meine, im generischen Fall kennt der Server nicht alle Benutzer, die jemals in einem bestimmten Raum, den er beherbergt, chatten könnten.
(Nun, wenn das das einzige Problem wäre, könnte es möglicherweise nur für Mitglieder-Zimmer funktionieren, ich muss zugeben.)
MUC-Räume sind nicht "nur lokale Server": Eine potenziell ungebundene Anzahl von Benutzern von einer beliebigen Anzahl anderer Server könnte dem Raum beitreten, und Nachrichten an diese Benutzer werden durch Weiterleitung über ihre jeweiligen Server zugestellt.
Offensichtlich ist dies ein weiterer Grund, warum solch eine Idee von "MUC-Raum-Offline-Speicher" keinen Sinn hat.
MUC-Räume sind definitionsgemäß vorübergehend: Wenn ein Benutzer offline ist, sind sie nicht in einem Raum - (wieder-) einmal in einem Raum ist eine explizite Aktion.
Dies ist in der Tat der wichtigste Grund, Offline-Speicher nicht zu unterstützen.
Wie Sie sehen können, sind XMPP MUC-Räume ähnlich wie IRC-Chats auf Steroiden.
Was Sie also wirklich wollen, ist "room history" - ein Teil von XMPP-0045 extension, mit der der Client den Raum explizit nach dem verpassten Nachrichtenverlauf fragen kann. In gewisser Weise könnte der Raum, anstatt für jeden Benutzer eine Offline-Nachricht zu speichern, so konfiguriert sein, dass er nur eine bestimmte Anzahl der zuletzt an ihn gesendeten Nachrichten (oder alle derartigen Nachrichten für einen bestimmten Zeitraum) speichert. Dann unterstützt der Raum die Abfrage dieser Nachrichten durch die verbundenen Benutzer.
Es gibt noch eine andere Möglichkeit, die Sie untersuchen könnten: "Multicast-Adressierung" von XEP-0033 ("Extended Zeilengruppe Adressierung "). Grundsätzlich ermöglicht es einem Client, einen speziellen Multicast-Dienst zu verwenden, um ihre Nachricht an mehrere Empfänger gleichzeitig zu senden. Der Vorteil ist, dass der Offline-Speicher wieder da ist. Der Nachteil ist, dass ich bezweifle, dass ein solcher Multicast-Dienst standardmäßig in ejabberd unterstützt wird, und es scheint so, als ob diese Erweiterung viele Details darüber offen lässt, wie sie unspezifiziert implementiert werden könnte.
Ich habe mich Ihrem Problem gestellt, als ich versucht habe, Gruppenchats für meine Chat-App zu implementieren. Ich hatte das gleiche Problem, dass MUC keine Offline-Nachrichten für jeden Empfänger speichert. Und ich wollte nicht MUC-Geschichte abrufen, die erfordert, dass der Benutzer jedem MUC wieder beitritt, um seine Nachrichten-Datenbank zu aktualisieren. Was ich wollte, ist, dass der Server Offline-Nachrichten nach Empfänger speichert und dass der Empfänger alle MUC-Nachrichten erhält, wenn er online ist (ohne an jedem MUC teilnehmen zu müssen).
Wie ich es gemacht habe, ist durch Pubsub. Wenn Sie pubsub verwenden, wird der Server gezwungen, eine Offline-Nachricht pro Empfänger zu speichern. Wenn der Benutzer die Verbindung wieder herstellt, erhält er alle Offline-Nachrichten einschließlich der pubsub-Nachrichten, die als normale Nachrichten gesendet werden - das ist es. Ein Problem, das ich mit Pubsub über MUC hatte, ist, dass es schwierig ist, die Liste der Abonnenten zu bekommen. Wenn meine App also einen Gruppenchat erstellt, erstellt sie einen Pubsub-Knoten für Nachrichten, lädt alle Teilnehmer zum Abonnieren (einschließlich selbst) des Pubsubs ein, und meine App erstellt auch einen MUC und macht jeden Teilnehmer zum Besitzer dieses MUC. Auf diese Weise kann die Liste der Groupchat-Teilnehmer durch Überprüfung der Eigentümerliste des MUC abgerufen werden. Der einzige Zweck des MUC besteht darin, sowohl die Teilnehmerliste als auch den Namen des Gruppenchats zu führen. Alles andere wird vom pubsub-Knoten erledigt.
Alles Unklarheiten bitte lass es mich wissen.
ZUSÄTZLICHE DETAILS: Wenn der Benutzer einen Gruppenchat erstellen möchte, erstellt unsere App im Wesentlichen einen Pubsub-Knoten sowie einen MUC. Sie müssen mit beiden Konzepten vertraut sein. Für den Pubsub-Knoten müssen Sie eine Option festlegen, die es jedem Abonnenten erlaubt, zu posten. Wenn ein Benutzer eine Nachricht sendet, veröffentlicht er sie tatsächlich auf dem Knoten, und ejabberd sendet die Nachricht an alle Abonnenten, als wäre es eine normale Nachricht (außer dass sie von pubsub.yourdomain.com kommt). Wenn ein Empfänger offline ist, speichert ejabberd diese Nachricht daher als jede andere reguläre Nachricht.
So behandelt ejabberd keine MUC-Nachrichten. Diese werden nur an Personen gesendet, die sich momentan im Chatroom befinden. Die Geschichte der Nachrichten kann jedoch von ejabberd gespeichert werden, aber damit ein Empfänger die Geschichte bekommen kann, muss er dem MUC beitreten. Das bedeutet, dass jedes Mal, wenn sich die App erneut verbindet, alle vorhandenen MUCs des Benutzers hinzugefügt werden müssen. Wir fanden das nicht praktisch.
Wir verwenden auch einen MUC für den gleichen Gruppenchat, aber dies dient nur dazu, Teilnehmer zu speichern, so dass ein Benutzer die Liste jederzeit abrufen kann (keine Möglichkeit, dies mit pubsub zu tun).
Ein zusätzlicher Vorteil von pubsub gegenüber MUC ist, dass die Art und Weise, wie ejabberd Pubsub-Daten speichert, viel effizienter ist. Ich habe das nicht gründlich studiert, aber ich erwarte von pubsub eine viel bessere Leistung.
Neuer ejabberd-Server in der 16.09-Version hat Verbesserungen für den Multi-User-Chat - MUC Sub:
Das Ziel von MUC Sub ist es, sich so weit wie möglich auf die bestehende MUC-Spezifikation zu verlassen und gleichzeitig die kleinste mögliche Änderung vorzunehmen, die den mobilen Gruppenkonversations-Client vereinfacht.
Die Funktion ist standardmäßig aktiviert. Um es zu verwenden, stellen Sie sicher, dass Sie den neuen Parameter "Abonnement zulassen" in dem Raum, in dem Sie ihn verwenden möchten, festlegen.
Hier ist der Link zur Dokumentation: Ссылка
Weitere Informationen hier: Ссылка