Quelle est la meilleure architecture pour passer à XMPP ?

Question

Si j'ai un système distinct avec son propre concept d'utilisateurs et de présence, quelle est l'architecture la plus appropriée pour créer un pont vers un réseau de serveurs XMPP ?Pour autant que je sache, il existe trois méthodes principales :

1. Agir en tant que serveur.Cela crée un point de contact, mais je crains que cela ait des implications sur la compatibilité et crée potentiellement une complexité dans mon système d'émulation d'un serveur.

2. Agir en tant que client.Cela semble impliquer que j'ai besoin d'une connexion par utilisateur dans mon système, ce qui ne va tout simplement pas bien évoluer.

3. J'ai entendu parler d'un protocole de passerelle XMPP, mais on ne sait pas s'il est meilleur que la solution client.Je ne peux pas non plus dire si c'est standard ou non.

Toute suggestion ou compromis serait apprécié.Par exemple, l'une de ces solutions nécessiterait-elle l'exécution de code sur le serveur XMPP cible (ce qui n'est probablement pas quelque chose que je puisse faire).

Answer 1

Le protocole de passerelle XMPP dont vous avez entendu parler concerne probablement les transports.Un transport est un serveur qui se connecte à la fois à un serveur XMPP et à un serveur non XMPP.En exécutant un transport, je peux utiliser mon client Jabber pour parler à quelqu'un en utilisant, par exemple, MSN Messenger.

Un transport se connecte généralement une fois au réseau distant pour chaque JID qu'il considère comme en ligne.Autrement dit, c'est votre option 2 à l'envers.En effet, il n'y a pas de relation particulière entre le transport et le réseau non XMPP ;le transport agit simplement comme un groupe de clients réguliers.Pour que cela fonctionne, les clients XMPP doivent d'abord s'inscrire auprès du transport, en fournissant les informations de connexion au réseau distant et en permettant au transport de visualiser leur présence.

La seule raison pour laquelle cela a une chance de mieux évoluer est qu'il peut y avoir de nombreux transports pour le même réseau distant.Par exemple, mon serveur Jabber pourrait exécuter un transport vers MSN, un autre serveur Jabber pourrait en exécuter un autre, et ainsi de suite, chacun fournissant des connexions à un sous-ensemble différent d'utilisateurs XMPP.Bien que cela répartisse la charge du côté Jabber et que l'équilibrage de charge sur votre système puisse également répartir la charge, cela nécessite néanmoins de nombreuses connexions entre les deux systèmes.

Dans votre cas, parce que (je suppose) le côté non-XMPP coopère, mettre une interface de serveur XMPP sur le serveur non-XMPP est probablement votre meilleur pari.Cette interface serveur est la mieux adaptée pour gérer le mappage entre les JID XMPP et la façon dont ce JID apparaîtra sur son propre réseau, plutôt que de forcer les utilisateurs XMPP à s'enregistrer, etc.

Si vous ne les avez pas vus, ils pourraient vous être utiles :

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

J'espère que cela pourra aider.

Answer 2

Moi aussi, je travaille sur un système similaire.

Je vais avec la route passerelle/composant.J'ai examiné plusieurs options et j'ai opté pour celle-ci.

La passerelle est essentiellement un composant dont le but spécifique est de relier Jabber/XMPP à un autre réseau.Vous devrez créer la plupart des éléments que vous prenez pour acquis lorsque vous utilisez XMPP en tant que client.Des trucs comme le contrôle des listes.

Il existe très peu d’aide en ligne sur la conception et la construction d’un composant.Comme la réponse ci-dessus, j'ai trouvé que les protocoles/extensions xmpp étaient utiles.Les principaux étant :

• Client de base 2008
• Serveur de base 2008
• Client intermédiaire 2008
• Serveur intermédiaire 2008

Leur lecture vous montrera quels XEP vous devrez être capable de gérer.Ignorez les éléments qui seront gérés par le serveur auquel votre composant sera connecté.

C'est dommage que Djabberd ait une documentation aussi pauvre car leur système de "tout est un module" donnait la possibilité au backend du serveur de s'interfacer directement avec l'autre réseau.Je n'ai fait aucun progrès à ce sujet.

Answer 3

Il existe essentiellement deux types de connexions de serveur à serveur (s2s).Le premier s’appelle soit une passerelle, soit un transport, mais c’est la même chose.C'est probablement le genre que vous recherchez.Je n'ai pas trouvé de documentation spécifique pour le côté non-XMPP, mais la façon dont XMPP envisage d'effectuer des traductions vers des serveurs existants est la suivante : http://xmpp.org/extensions/xep-0100.html.Le deuxième type n'est vraiment expliqué dans aucun XEP supplémentaire - il s'agit de connexions XMPP s2s classiques.Recherchez « Communication de serveur à serveur » dans la RFC 3920 ou la RFC 3920bis pour connaître la dernière version préliminaire de la mise à jour.

Puisque vous avez vos propres utilisateurs et présence sur votre serveur, et qu'il ne s'agit pas de XMPP, les concepts ne vont pas correspondre complètement au modèle XMPP.C'est là qu'intervient le travail du transport.Vous devez faire la traduction de votre modèle vers le modèle XMPP.Même si cela demande du travail, vous prenez toutes les décisions.

Ce qui nous amène directement à l'un des choix de conception clés : vous devez vraiment décider quels éléments vous allez mapper vers XMPP à partir de votre service et ce que vous ne l'êtes pas.Ces descriptions de fonctionnalités et de cas d’utilisation détermineront la structure globale.Par exemple, est-ce comme un moyen de transport pour parler aux services de chat d'AOL ou de MSN ?Ensuite, vous aurez besoin d'un moyen de mapper leur équivalent en termes de listes, de présence et de conserver les informations de session ainsi que les identifiants et les mots de passe de vos utilisateurs locaux sur le serveur distant.En effet, votre moyen de transport devra se faire passer pour ces utilisateurs et devra se connecter pour eux.

Ou, peut-être que vous n'êtes qu'un pont s2s vers le jeu d'échecs basé sur XMPP de quelqu'un d'autre, vous n'avez donc pas besoin de vous connecter sur le serveur distant et pouvez simplement agir de la même manière qu'un serveur de messagerie et transmettre les informations dans les deux sens.(Avec des connexions s2s normales, la seule session qui serait stockée serait l'authentification SASL utilisée avec le serveur distant, mais au niveau de l'utilisateur, s2s maintient simplement la connexion, et non la session de connexion.)

D'autres facteurs sont l'évolutivité et la modularité de votre côté.Vous avez résolu certains problèmes d'évolutivité.Pensez à effectuer plusieurs transports pour équilibrer la charge.Pour plus de modularité, voyez où vous souhaitez prendre des décisions sur ce qu'il faut faire avec chaque paquet ou action.Par exemple, comment gérez-vous et suivez-vous les données d’abonnement ?Vous pouvez le mettre sur votre transport, mais cela rend l'utilisation de plusieurs transports plus difficile.Ou si vous prenez cette décision plus près de votre serveur principal, vous pouvez avoir des transports plus simples et utiliser du code commun si vous avez besoin de parler à des services autres que XMPP.Le compromis est un serveur principal plus complexe avec plus de potentiel de vulnérabilité.

Answer 4

L'architecture que vous devez utiliser dépend du système non XMPP.

1. Exploitez-vous le système non-XMPP ?Si oui, vous devriez trouver un moyen d'ajouter une interface XMPP-S2S à ce système, en d'autres termes, de le faire agir comme un serveur XMPP.AOL utilise cette approche pour AIM.Malheureusement, ils ont restreint leur passerelle vers GoogleTalk.

2. Vous n'utilisez pas le système non-XMPP mais il dispose d'une interface de fédération que vous pouvez utiliser - i.e.votre passerelle peut parler à l'autre système en tant que serveur et possède son propre espace de noms.Dans ce cas, vous pouvez créer une passerelle qui agit comme un serveur fédéré des deux côtés.Car je ne connais aucun exemple de passerelle utilisant cette approche, mais vous pouvez l'utiliser si vous souhaitez créer un pont public XMPP vers SIP.

3. Si le système non-XMPP ne vous offre pas d'interface de fédération, vous n'avez d'autre choix que d'agir comme un groupe de clients.Dans le monde XMPP, cela s'appelle un « transport ».Les différences entre un transport et un serveur normal sont essentiellement :

   • les JID du transport sont mappés à partir d'un autre système (par ex.john.doe\40example.net@msngateway.example.org - vraiment moche !)
   • Les utilisateurs XMPP qui souhaitent utiliser le transport doivent créer un compte sur le système non XMPP et donner les informations de connexion de ce compte au service de transport.Le protocole XMPP possède même une extension de protocole qui permet aux utilisateurs XMPP d'effectuer des enregistrements de transport intrabande.

Answer 5

Une autre approche consiste à travailler avec votre fournisseur de serveur XMPP.La plupart disposent d’API internes qui permettent d’injecter de la présence à partir d’applications tierces.Par exemple, Jabber XCP fournit pour cela une API très facile à utiliser.

(Divulgation:Je travaille pour Jabber, Inc, la société derrière Jabber XCP)