Was ist die beste Architektur für die Überbrückung zu XMPP?

https://stackoverflow.com/questions/35677

09-06-2019
|

Frage

Wenn ich ein separates System mit eigenem Benutzer- und Präsenzkonzept habe, welche Architektur ist dann am besten geeignet, um eine Brücke zu einem XMPP-Servernetzwerk zu erstellen?Soweit ich das beurteilen kann, gibt es drei Hauptwege:

Fungieren Sie als Server.Dadurch entsteht ein Berührungspunkt, aber ich befürchte, dass dies Auswirkungen auf die Kompatibilität hat und möglicherweise zu einer Komplexität in meinem System für die Emulation eines Servers führt.
Handeln Sie als Kunde.Dies scheint zu bedeuten, dass ich in meinem System eine Verbindung pro Benutzer benötige, was sich einfach nicht gut skalieren lässt.
Ich habe von einem XMPP-Gateway-Protokoll gehört, aber es ist unklar, ob dieses besser ist als die Client-Lösung.Ich kann auch nicht sagen, ob das Standard ist oder nicht.

Für Vorschläge oder Kompromisse wäre ich dankbar.Würde eine dieser Lösungen beispielsweise erfordern, dass Code auf dem Ziel-XMPP-Server ausgeführt wird (was ich wahrscheinlich nicht tun kann)?

Lösung

Das XMPP-Gateway-Protokoll, von dem Sie gehört haben, hat am ehesten etwas mit Transporten zu tun.Ein Transport ist ein Server, der sowohl eine Verbindung zu einem XMPP-Server als auch zu einem Nicht-XMPP-Server herstellt.Indem ich einen Transport ausführe, kann ich meinen Jabber-Client verwenden, um mit jemandem zu sprechen, der beispielsweise MSN Messenger verwendet.

Ein Transport stellt normalerweise für jede JID, die er als online erkennt, einmal eine Verbindung zum Remote-Netzwerk her.Das heißt, es ist Ihre umgekehrte Option 2.Dies liegt daran, dass zwischen dem Transport und dem Nicht-XMPP-Netzwerk keine besondere Beziehung besteht.Der Transport fungiert lediglich als Gruppe von Stammkunden.Damit dies funktioniert, müssen sich XMPP-Clients zunächst beim Transport registrieren, Anmeldeinformationen für das Remote-Netzwerk angeben und dem Transport ermöglichen, ihre Anwesenheit anzuzeigen.

Der einzige Grund, warum dies eine Chance auf eine bessere Skalierung hat, besteht darin, dass es viele Transporte für dasselbe Remote-Netzwerk geben kann.Beispielsweise könnte mein Jabber-Server eine Übertragung zu MSN ausführen, ein anderer Jabber-Server könnte einen anderen ausführen usw., wobei jeder Server Verbindungen für eine andere Untergruppe von XMPP-Benutzern bereitstellt.Während dadurch die Last auf der Jabber-Seite verteilt wird und der Lastausgleich auf Ihrem System die Last ebenfalls verteilen kann, sind dennoch viele Verbindungen zwischen den beiden Systemen erforderlich.

In Ihrem Fall ist die Installation einer XMPP-Serverschnittstelle auf dem Nicht-XMPP-Server wahrscheinlich die beste Wahl, da (ich nehme an) die Nicht-XMPP-Seite kooperiert.Diese Serverschnittstelle eignet sich am besten für die Verwaltung der Zuordnung zwischen XMPP-JIDs und für die Darstellung dieser JID in ihrem eigenen Netzwerk, anstatt XMPP-Benutzer zur Registrierung usw. zu zwingen.

Falls Sie diese noch nicht gesehen haben, könnten sie für Sie nützlich sein:

Hoffentlich hilft das.

Andere Tipps

Auch ich arbeite an einem ähnlichen System.

Ich wähle die Gateway/Komponenten-Route.Ich habe mir mehrere Optionen angesehen und mich für diese entschieden.

Das Gateway ist im Grunde eine Komponente mit dem spezifischen Zweck, Jabber/XMPP mit einem anderen Netzwerk zu verbinden.Die meisten Dinge, die Sie für selbstverständlich halten, wenn Sie XMPP als Client verwenden, müssen Sie selbst erstellen.Dinge wie Dienstplankontrolle.

Es gibt online nur sehr wenig Hilfe zum eigentlichen Design und Bau einer Komponente.Wie bei der obigen Antwort habe ich festgestellt, dass die xmpp-Protokolle/-Erweiterungen hilfreich sind.Die wichtigsten sind:

Wenn Sie diese durchlesen, erfahren Sie, mit welchen XEPs Sie voraussichtlich umgehen können.Ignorieren Sie die Dinge, die vom Server verarbeitet werden, an den Ihre Komponente angehängt wird.

Es ist eine Schande, dass Djabberd über eine so schlechte Dokumentation verfügt, da das System „Alles ist ein Modul“ die Möglichkeit bietet, dass das Backend des Servers direkt mit dem anderen Netzwerk verbunden werden kann.Ich bin dabei nicht weitergekommen.

Grundsätzlich gibt es zwei Arten von Server-zu-Server-Verbindungen (S2S).Das erste wird entweder Gateway oder Transport genannt, ist aber dasselbe.Dies ist wahrscheinlich die Art, nach der Sie suchen.Ich konnte keine spezifische Dokumentation für die Nicht-XMPP-Seite finden, aber wie XMPP über Übersetzungen auf Legacy-Server denkt, finden Sie hier http://xmpp.org/extensions/xep-0100.html.Die zweite Art wird in keinem weiteren XEPs wirklich erklärt – es handelt sich um reguläre XMPP-s2s-Verbindungen.Suchen Sie nach „Server-zu-Server-Kommunikation“ in RFC 3920 oder RFC 3920bis für den neuesten Aktualisierungsentwurf.

Da Sie über eigene Benutzer und eine eigene Präsenz auf Ihrem Server verfügen und es sich nicht um XMPP handelt, lassen sich die Konzepte nicht vollständig auf das XMPP-Modell abbilden.Hier kommt die Arbeit des Transports ins Spiel.Sie müssen die Übersetzung von Ihrem Modell in das XMPP-Modell durchführen.Das ist zwar etwas Arbeit, aber Sie können alle Entscheidungen treffen.

Das bringt uns direkt zu einer der wichtigsten Designentscheidungen: Sie müssen wirklich entscheiden, welche Dinge Sie von Ihrem Dienst zu XMPP zuordnen möchten und welche nicht.Diese Funktions- und Anwendungsfallbeschreibungen bestimmen die Gesamtstruktur.Handelt es sich beispielsweise um eine Art Fortbewegungsmittel, um mit AOL- oder MSN-Chat-Diensten zu sprechen?Dann benötigen Sie eine Möglichkeit, die entsprechenden Dienstpläne, Anwesenheits- und Sitzungsinformationen sowie Anmelde- und Passwörter Ihrer lokalen Benutzer auf dem Remote-Server abzubilden.Dies liegt daran, dass Ihr Transportmittel vorgeben muss, diese Benutzer zu sein, und sich für sie anmelden muss.

Oder vielleicht sind Sie nur eine S2S-Brücke zum XMPP-basierten Schachspiel einer anderen Person, sodass Sie keine Anmeldung auf dem Remote-Server benötigen und einfach wie ein E-Mail-Server agieren und die Informationen hin und her weiterleiten können.(Bei normalen S2S-Verbindungen wäre die einzige Sitzung, die gespeichert würde, die SASL-Authentifizierung, die mit dem Remote-Server verwendet wird, aber auf Benutzerebene verwaltet s2s nur die Verbindung und nicht die Anmeldesitzung.)

Weitere Faktoren sind Skalierbarkeit und Modularität auf Ihrer Seite.Sie haben einige der Skalierbarkeitsprobleme geklärt.Versuchen Sie, mehrere Transporte einzusetzen, um die Ladung auszugleichen.Für die Modularität sehen Sie, wo Sie Entscheidungen darüber treffen möchten, was mit den einzelnen Paketen oder Aktionen geschehen soll.Wie gehen Sie beispielsweise mit Abonnementdaten um und behalten den Überblick darüber?Sie können es auf Ihrem Transportmittel anbringen, aber das erschwert dann die Verwendung mehrerer Transportmittel.Oder wenn Sie diese Entscheidung näher an Ihrem Kernserver treffen, können Sie einfachere Transporte nutzen und einen gemeinsamen Code verwenden, wenn Sie mit anderen Diensten als XMPP kommunizieren müssen.Der Kompromiss ist ein komplexerer Kernserver mit mehr Schwachstellenpotenzial.

Welche Architektur Sie verwenden sollten, hängt vom Nicht-XMPP-System ab.

Betreiben Sie das Nicht-XMPP-System?Wenn ja, sollten Sie eine Möglichkeit finden, diesem System eine XMPP-S2S-Schnittstelle hinzuzufügen, d. h. es als XMPP-Server fungieren zu lassen.AOL nutzt diesen Ansatz für AIM.Leider haben sie ihr Gateway auf GoogleTalk eingeschränkt.
Sie betreiben das Nicht-XMPP-System nicht, aber es verfügt über eine Federation-Schnittstelle, die Sie nutzen können – d.e.Ihr Gateway kann mit dem anderen System kommunizieren als Server und verfügt über einen eigenen Namensraum.In diesem Fall können Sie ein Gateway erstellen, das auf beiden Seiten als Verbundserver fungiert.Denn ich kenne kein Beispiel für ein Gateway, das diesen Ansatz verwendet, aber Sie könnten ihn verwenden, wenn Sie eine öffentliche XMPP-zu-SIP-Brücke bauen möchten.
Wenn das Nicht-XMPP-System Ihnen keine Föderationsschnittstelle bietet, haben Sie keine andere Wahl, als als eine Gruppe von Clients zu agieren.In der XMPP-Welt wird dies als „Transport“ bezeichnet.Die Unterschiede zwischen einem Transport- und einem normalen Server sind im Wesentlichen:
- die JIDs des Transports werden aus einem anderen System (z.B.john.doe\40example.net@msngateway.example.org – wirklich hässlich!)
- XMPP-Benutzer, die den Transport nutzen möchten, müssen ein Konto auf dem Nicht-XMPP-System erstellen und die Anmeldeinformationen dieses Kontos an den Transportdienst weitergeben.Das XMPP-Protokoll verfügt sogar über eine Protokollerweiterung, die es XMPP-Benutzern ermöglicht, Transportregistrierungen im Band durchzuführen.

Ein anderer Ansatz besteht darin, mit Ihrem XMPP-Serveranbieter zusammenzuarbeiten.Die meisten verfügen über interne APIs, die das Einschleusen von Präsenz aus Drittanwendungen ermöglichen.Zum Beispiel, Jabber XCP stellt hierfür eine API bereit, die wirklich einfach zu verwenden ist.

(Offenlegung:Ich arbeite für Jabber, Inc, das Unternehmen hinter Jabber XCP.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow