Jabber-Gateway

Ein Jabber-Transport (auch Jabber-Agent oder Jabber-Gateway) ist ein Dienst innerhalb eines Jabber-Netzwerkes, der Nutzer anderer Instant Messaging-Systeme transparent als Jabber-Nutzer repräsentiert.

Hiermit ist es möglich, andere Netzwerke (oft als Legacy Services bezeichnet) wie AIM, ICQ, Y!M, Gadu-Gadu oder IRC zu verwenden und mit deren Benutzern zu interagieren. Auch zu MSN ist das möglich, allerdings schalten viele Administratoren diesen Transport aus rechtlichen Gründen ab. Anders als bei Multi-Protokoll-Clients funktioniert die Verbindung zu Fremdnetzen bei Jabber nicht dadurch, dass die notwendigen Protokolle auf Clientseite unterstützt werden, stattdessen wird die Anbindung zu Fremdnetzen von Jabber-Servern zur Verfügung gestellt. Die Server „übersetzen“ dabei die Nachrichten zwischen den Netzwerken, ohne dass die beiden beteiligten Benutzer hierfür besondere Vorkehrungen treffen müssen.

Funktionsweise

Folgendes Beispiel soll den Ablauf zwischen Alice, die einen Jabber-Client benutzt und Bob, der bei ICQ registriert ist, veranschaulichen:

• Alice übergibt dem Transport zunächst ihre ICQ-Anmeldedaten (ICQ-Nummer und Passwort).
• Daraufhin loggt sich der Transport im Auftrag von Alice bei ICQ ein und verhält sich dem ICQ-Netzwerk gegenüber wie ein normaler ICQ-Client. Einerseits überträgt der Transport nun alle Nachrichten von Bob (im ICQ-Netzwerk) an den Jabber-Client von Alice. Andererseits leitet er alle Nachrichten von Alice an Bob weiter.
• Bob bekommt von diesem Ablauf nichts mit. Ihm erscheint es so, als ob er direkt mit Alice kommunizieren würde.
• In der Kontaktliste (bei Jabber „Roster“ genannt) von Alice wird Bob als „normaler“ Jabber-User dargestellt, obwohl er nicht mit dem Jabber-, sondern mit dem ICQ-Netzwerk verbunden ist.

Alice sendet ihre Nachricht erst zu dem Jabber-Server an dem sie angemeldet ist, dann zum Jabber-Transport. Dieser leitet sie über den ICQ-Server zu Bob weiter.

Jeder Benutzer von Jabber kann sich bei Transports registrieren, indem er seine vorhandenen Login-Informationen an diesen Dienst übergibt. Dazu müssen Clients Service Discovery^[1] (kurz disco, zu deutsch „Dienste durchsuchen“) unterstützen. So ist es möglich, Server nach angebotenen Transports zu durchsuchen und ohne zusätzliche Installation von Plugins, Kommunikation mit Nutzern proprietärer Instant-Messaging-Netzwerke zu betreiben.

Obwohl das Jabber-Protokoll bezüglich der Umsetzung von Funktionen von Fremdnetzen keine Einschränkungen vorgibt, unterstützen die aktuellen Transports nur Basisfunktionen (Senden und Empfangen von Nachrichten, Sichtbarkeiten). Sofern Datentransfers und Chaträume unterstützt werden, ist die Nutzung zumeist nur eingeschränkt möglich.

Der Transport selbst wird auch durch einen Jabber Identifier repräsentiert. So kann man z. B. die Sichtbarkeit oder Abwesenheitsnachricht für das jeweilige Netz gesondert setzen, oder „für den Transport offline sein“, was ein Ausloggen aus dem jeweiligen Dienst bewirkt.

Vorteile

Der Vorteil dieses Konzepts ist, dass ein großer Teil der Komplexität von den Clients auf die Transports abgewälzt wird. Das erlaubt die Herstellung von reinen Jabber-Clients, die ohne Transports eine zu kleine Akzeptanz hätten.

Reine Jabber-Clients sind erheblich einfacher zu programmieren und zu warten, zumal das Jabber-Protokoll wegen der öffentlichen und stabilen Spezifikation gut implementiert werden kann. Davon profitiert letztlich der Endanwender, weil dadurch die Vielfalt der Clients steigt.

Außerdem müssen Updates im Umgang mit den Fremd-Protokollen nicht durch neue Client-Versionen verteilt werden. Stattdessen wird nur die Server-Software aktualisiert, und alle Clients profitieren unmittelbar von den Änderungen.

Ein weiterer Vorteil ist die größere Homogenität in der Benutzerführung, die reine Jabber-Clients bieten. Die ist zwar nicht zwingend auf reine Jabber-Clients beschränkt, de facto verführen die speziellen Eigenschaften der Fremdprotokolle allerdings die Hersteller von Multi-Protokoll-Clients zu komplexeren Konfigurationsfenstern.

Nachteile

Die Transports werden von vielen Nutzern aufgrund unbefriedigender Verlässlichkeit und Stabilität sowie der hohen serverseitigen Last nur als Notlösung betrachtet. Sie sehen den Sinn der Nutzung vor allem darin, während der Übergangszeit die bisherigen Kontakte, die noch proprietäre Netzwerke nutzen, in Jabber verfügbar zu haben. Dennoch wird von vielen Nutzern auch der Dauereinsatz als gerechtfertigt angesehen, zumal nicht alle Kontakte Interesse an einer Migration zu Jabber haben.

Generell wird empfohlen, einen Transport zu wählen, der

1. nicht zu den großen, bekannten Servern gehört und trotzdem
2. gut betreut und zeitnah aktualisiert wird.

Bekannte Software für Jabber-Transports

Funktionalitätsreiche, in Python aktiv entwickelte Transports sind:

• PyICQt
• PyAIMt
• PyMSNt
• PyIRCt

Andere, frühe Implementierungen die teilweise noch in den Paketlisten einiger Distributoren enthalten sind nutzten einen Fork des jabberd.

Kommerzielle Anbieter bieten auch Gateways vom Jabber- ins GSM-Netz für den transparenten SMS-Versand an.

Links

Seite mit vielen verschiedenen Servern die unterschiedlichste Transports anbieten: http://www.jabberes.org/servers/servers.html

Dokumente

• XEP 100: Gateway Interaction
• XEP 30: Service Discovery

Einzelnachweise

1. ↑ Jabber Software Foundation: JEP-0030: Service Discovery Version 2.2, 24. Januar 2006