Qual è la migliore architettura per collegare XMPP?

Question

Se dispongo di un sistema separato con un proprio concetto di utenti e presenza, qual è l'architettura più appropriata per creare un bridge verso una rete di server XMPP?Per quanto ne so ci sono tre modi principali:

1. Agisci come un servitore.Ciò crea un punto di contatto, ma temo che abbia implicazioni per la compatibilità e potenzialmente crei complessità nel mio sistema per l'emulazione di un server.

2. Agisci come un cliente.Ciò sembra implicare che ho bisogno di una connessione per utente nel mio sistema, che semplicemente non si adatterà bene.

3. Ho sentito parlare di un protocollo gateway XMPP, ma non è chiaro se sia migliore della soluzione client.Inoltre non riesco a capire se questo è standard o meno.

Eventuali suggerimenti o compromessi sarebbero apprezzati.Ad esempio, una qualsiasi di queste soluzioni richiederebbe l'esecuzione di codice all'interno del server XMPP di destinazione (probabilmente non è qualcosa che posso fare).

Answer 1

Il protocollo gateway XMPP di cui hai sentito parlare ha molto probabilmente a che fare con i trasporti.Un trasporto è un server che si connette sia a un server XMPP che a un server non XMPP.Eseguendo un trasporto, posso utilizzare il mio client Jabber per parlare con qualcuno che utilizza, ad esempio, MSN Messenger.

Un trasporto in genere si connette una volta alla rete remota per ciascun JID che vede come online.Cioè, è la tua opzione 2 al contrario.Questo perché non esiste una relazione speciale tra il trasporto e la rete non XMPP;il trasporto agisce semplicemente come un gruppo di clienti abituali.Affinché ciò funzioni, i client XMPP devono prima registrarsi con il trasporto, fornendo le credenziali di accesso per la rete remota e consentendo al trasporto di visualizzare la loro presenza.

L'unico motivo per cui questo ha una possibilità di scalabilità migliore è che possono esserci molti trasporti per la stessa rete remota.Ad esempio, il mio server Jabber potrebbe eseguire un trasporto verso MSN, un altro server Jabber potrebbe eseguirne un altro e così via, ognuno dei quali fornisce connessioni per un diverso sottoinsieme di utenti XMPP.Anche se questo distribuisce il carico sul lato Jabber e anche il bilanciamento del carico sul sistema può distribuire il carico, richiede comunque molte connessioni tra i due sistemi.

Nel tuo caso, poiché (presumo) il lato non XMPP delle cose sta collaborando, mettere un'interfaccia server XMPP sul server non XMPP è probabilmente la soluzione migliore.Quell'interfaccia server è più adatta per gestire la mappatura tra i JID XMPP e il modo in cui tale JID apparirà sulla propria rete, piuttosto che forzare gli utenti XMPP a registrarsi e così via.

Nel caso non li avessi visti, potresti trovarli utili:

• http://www.jabber.org/jabber-for-geeks/technology-overview
• http://www.xmpp.org/protocols/
• http://www.xmpp.org/extensions/

Spero che aiuti.

Answer 2

Anch'io sto lavorando su un sistema simile.

Sto andando con il percorso gateway/componente.Ho esaminato diverse opzioni e ho optato per questa.

Il gateway è fondamentalmente un componente con lo scopo specifico di collegare Jabber/XMPP con un'altra rete.Dovrai creare la maggior parte delle cose che dai per scontate quando usi XMPP come client.Roba come il controllo degli elenchi.

C'è pochissimo aiuto online sulla progettazione e sulla costruzione effettiva di un componente.Come la risposta sopra, ho scoperto che i protocolli/estensioni xmpp sono di aiuto.I principali sono:

• Cliente di base 2008
• Server di base 2008
• Cliente intermedio 2008
• Server intermedio 2008

Leggendoli ti mostrerai quali XEP dovrai essere in grado di gestire.Ignora le cose che verranno gestite dal server a cui sarà collegato il tuo componente.

È un peccato che Djabberd abbia una documentazione così scarsa poiché il loro sistema "tutto è un modulo" dava la possibilità che il backend del server potesse interfacciarsi direttamente con l'altra rete.Non ho fatto alcun progresso su questo.

Answer 3

Esistono fondamentalmente due tipi di connessioni da server a server (s2).Il primo è chiamato gateway o trasporto, ma sono la stessa cosa.Questo è probabilmente il tipo che stai cercando.Non sono riuscito a trovare documentazione specifica per il lato non XMPP, ma il modo in cui XMPP pensa di eseguire traduzioni su server legacy è su http://xmpp.org/extensions/xep-0100.html.Il secondo tipo in realtà non è spiegato in nessun XEP aggiuntivo: si tratta di normali connessioni XMPP s2s.Cerca "Comunicazione da server a server" in RFC 3920 o RFC 3920bis per l'ultima bozza di aggiornamento.

Dato che hai i tuoi utenti e la tua presenza sul tuo server, e non è XMPP, i concetti non verranno mappati completamente al modello XMPP.È qui che entra in gioco il lavoro dei trasporti.Devi fare la traduzione dal tuo modello al modello XMPP.Anche se questo è un po' di lavoro, puoi prendere tutte le decisioni.

Il che ci porta direttamente a una delle scelte progettuali chiave: devi davvero decidere quali cose mapperai su XMPP dal tuo servizio e cosa no.Queste descrizioni di funzionalità e casi d'uso guideranno la struttura complessiva.Ad esempio, è come un mezzo di trasporto per parlare con i servizi di chat di AOL o MSN?Quindi avrai bisogno di un modo per mappare l'equivalente di elenchi, presenza e conservare le informazioni sulla sessione insieme a accessi e password dagli utenti locali al server remoto.Questo perché il tuo mezzo di trasporto dovrà fingere di essere quegli utenti e dovrà effettuare il login per loro.

O forse sei solo un ponte s2s verso il gioco di scacchi basato su XMPP di qualcun altro, quindi non hai bisogno di un accesso sul server remoto e puoi semplicemente agire in modo simile a un server di posta elettronica e passare le informazioni avanti e indietro.(Con le normali connessioni s2s l'unica sessione che verrebbe archiviata sarebbe l'autenticazione SASL utilizzata con il server remoto, ma a livello utente s2s mantiene solo la connessione e non la sessione di accesso.)

Altri fattori sono la scalabilità e la modularità da parte tua.Hai risolto alcuni dei problemi di scalabilità.Dai un'occhiata all'inserimento di più trasporti per bilanciare il carico.Per la modularità, vedi dove vuoi prendere decisioni su cosa fare con ciascun pacchetto o azione.Ad esempio, come gestisci e tieni traccia dei dati di abbonamento?Puoi metterlo sul tuo trasporto, ma ciò rende più difficile l'utilizzo di più trasporti.Oppure, se prendi questa decisione più vicino al tuo server principale, puoi avere trasporti più semplici e utilizzare un codice comune se hai bisogno di comunicare con servizi diversi da XMPP.Il compromesso è un server core più complesso con un maggiore potenziale di vulnerabilità.

Answer 4

L'architettura da utilizzare dipende dal sistema non XMPP.

1. Utilizzi il sistema non XMPP?Se sì, dovresti trovare un modo per aggiungere un'interfaccia XMPP-S2S a quel sistema, in altre parole, farlo funzionare come un server XMPP.AOL sta utilizzando questo approccio per AIM.Sfortunatamente, hanno limitato il loro gateway per GoogleTalk.

2. Non gestisci il sistema non XMPP ma ha un'interfaccia federativa che puoi utilizzare: i.e.il tuo gateway può parlare con l'altro sistema come servitore e ha uno spazio dei nomi proprio.In questo caso, puoi creare un gateway che funga da server federato su entrambi i lati.Perché non conosco nessun esempio di gateway che utilizzi questo approccio, ma potresti usarlo se vuoi costruire un bridge pubblico da XMPP a SIP.

3. Se il sistema non XMPP non ti fornisce un'interfaccia federativa, non hai altra scelta che agire come un gruppo di client.Nel mondo XMPP, questo è chiamato "trasporto".Le differenze tra un trasporto ed un normale server sono sostanzialmente:

   • i JID del trasporto sono mappati da un altro sistema (es.john.doe\40example.net@msngateway.example.org - davvero brutto!)
   • Gli utenti XMPP che desiderano utilizzare il trasporto devono creare un account sul sistema non XMPP e fornire le credenziali di accesso di tale account al servizio di trasporto.Il protocollo XMPP dispone anche di un'estensione che consente agli utenti XMPP di effettuare registrazioni di trasporto in banda.

Answer 5

Un altro approccio consiste nel collaborare con il fornitore del server XMPP.La maggior parte dispone di API interne che rendono possibile l'inserimento della presenza da applicazioni di terze parti.Per esempio, Jabber XCP fornisce un'API davvero facile da usare.

(Divulgazione:Lavoro per Jabber, Inc, la società dietro Jabber XCP)