Jabber

Seit heute betreiben wir (wie schon einmal angedroht) auf unserem Jabber/XMPP-Server eine c2s-Komponente, die alle bei uns gehosteten Domains bedient und auf den wohlbekannten Standard-Ports 5222 und 5223 (klassisches SSL) horcht.

Für ganz restriktive Umgebungen haben wir noch die Ports 80 (HTTP) und 443 (HTTPS) hinzugefügt. Damit sollte der Dienst wohl für alle Nutzer von überall erreichbar sein. Auf den von vorne herein verschlüsselten Ports liefern wir unser SSL-Zertifikat für ssl.tiggerswelt.net aus - das ist nicht direkt schön, aber offiziell signiert. Für die modernere StartTLS-Variante funktionieren die jeweiligen Kunden-/Domain-spezifischen SSL-Zertifikate bzw. wieder unser SSL-Zertifikat als Fall-Back.

Einziger Nachteil bei dieser Variante: Änderungen auf Kundendomains spielen wir maximal alle 2 Stunden ein. Das bedeutet zum einen, dass Änderungen an der XMPP-Konfiguration wie z.B. verwendetes Zertifikat, Passwort-Änderungen oder Benutzer-Registrierung werden nur stark verzögert übernommen. Zudem kann es dann entsprechend im "worst case" zu einem Disconnect aller Nutzer auf dieser Komponente kommen.

Ich bin mal gespannt, wie viele die neue Variante nutzen werden und wie oft da tatsächlich neu gestartet wird.

Ich habe gestern nun endlich aktiv damit begonnen, unseren Jabber/XMPP-Server um eine MUC-Komponente zu erweitern.

Ein wenig überrascht war ich schon, denn bevor ich zur eigentlichen Arbeit gekommen bin, hagelte es erst einmal ein paar Patches für meine Event-Bibliothek, meine XMPP-Komponente und natürlich auch die recht generische MUC-Implementation von mir.

Am Ende des Tages war ich dann aber doch recht zufrieden und fast schon wieder im Arbeitsrausch. Die Sache mit dem Klappe halten hat bei einem kurzen Test auf unserem Produktiv-Server recht gut funktioniert, wenngleich mich die 700 KB an Traffic überrascht haben, die bei einem einfach Start der Komponente mit Authentifizierung und dem Bekanntmachen mit anderen Komponenten auf dem Server (presence und Service-Discovery) verbraten wurden.

Was jetzt noch fehlt ist das dynamische Hinzufügen und Entfernen von MUC-Domains und alles, was so zu einem Chat-Raum dazu gehört - wobei beides wohl weniger ist, als es klingt - und natürlich jede Menge Ideen, die das Ding einzigartig machen

Wer schon eine Jabber/XMPP-Instanz bei uns hat und an einer Public-Beta interessiert ist, darf mich gerne mal anschreiben.

Wir betreiben ja bekanntlich einen Jabber/XMPP-Server mit einigen Domains unserer Kunden.

Vergangene Woche kam hierzu die Frage auf, ob es eigentlich möglich ist, hier eine Komponente anzuschließen, die nicht bei jeder Domain (in der Service-Discovery) als verfügbarer Dienst angezeigt wird. Gerade wenn es darum geht personalisierte Dienste auf den Domains der Kunden oder speziell gebuchte Dienste für einen speziellen Kunden anzubieten.

Die Antwort hierauf ist recht einfach: Ja, es geht!

Ganz egal, ob die Komponenten mittels XEP-0114 oder mit dem nativen Component-Protocol des Jabberd2 (bzw. hier sobald eine Domain gebunden wird) an den Server "angeschlossen" werden, der Router sendet immer einen <presence>-Tag an alle anderen Komponenten, darunter auch die Session-Manager für die Kundendomains. Diese veranlassen daraufhin eine Service-Discovery, deren Ergebnis sie zwischenspeichern und bei eingehenden Anfragen einfach weiterreichen. Wenn wir also nicht wollen, dass ein Dienst unterhalb einer bestimmten Kundendomain angezeigt wird, unterlassen wir einfach Service-Discovery-Antworten an diese Domain.

Schade nur, dass ich selbst auf die Idee kommen musste und mir eigentlich keine Komponente auf dem freien Markt bekannt ist, die so eine Funktionalität von Haus aus anbieten würde. Egal, ich muss das Rad ja sowieso immer neu erfinden