Aperçu technique

De Wiki JabberFR
Révision datée du 26 mars 2010 à 21:19 par Ner0lph (discussion | contributions) (→‎Un rapide exemple : mise en forme liste ordonnée)
Aller à la navigation Aller à la recherche

Ce document fournit un aperçu technique haut-niveau des technologies Jabber/XMPP.

Introduction

Le terme « XMPP » (anciennement Jabber) est largement utilisé pour désigner un ensemble de protocoles ouverts permettant l'échange de données XML entre deux points quelconques d'un réseau. Mais aussi, pour désigner les technologies utilisant ces protocoles. Bien que XMPP soit principalement connu comme étant une plate-forme de messagerie instantanée et de présence (similaire aux anciens systèmes de MI comme AIM, ICQ, MSN/WLM, et Yahoo!) basé sur XML, le cœur du protocole procure une infrastructure de streaming XML qui est utilisé pour une large variété de systèmes de communication en temps réel.

Ce document propose un petit aperçu technique de l'architecture des technologies XMPP pour la messagerie instantanée et l'échange de présence, bien que beaucoup des principes abordés ici peuvent s'appliquer de manière plus générale. Pour plus d'informations concernant le protocole de XMPP, allez faire un tour sur le site http://xmpp.org/.

Un rapide exemple

L'architecture du système XMPP est très similaire à celle du système de messagerie le plus éprouvé de la planète : l'e-mail. Bien qu'il y ait des différences fondamentales, si vous voyez XMPP comme un « e-mail instantané », vous n'aurez pas vraiment tord. Alors comment est-ce que ça marche vraiment ? Pour comprendre comment, regardons d'abord un rapide exemple : Roméo et Juliette et la fameuse scène du balcon de Shakespeare.

Juliette n'envoie pas de message directement (« pair à pair ») à Roméo, du moins pas dans le monde de XMPP. Juliette à un compte sur un serveur XMPP, et son identifiant Jabber (ou « JID ») ressemble beaucoup à une adresse e-mail. Comme Juliette est une Capulet, elle enregistre son nom d'utilisateur « juliette » avec le serveur XMPP tournant sur capulet.com, comme ça son JID est juliette@capulet.com. De la même manière, Roméo a un compte sur le serveur de sa famille et son JID est romeo@montague.net.

Une fois que Juliette est connectée sur le serveur capulet.com, elle peut envoyer des messages à son ami. Pour être précis, voila ce qu'il se passe lorsque Juliette lance son client windows de son ordinateur portable, sur le balcon :

  1. Juliette envoie un message adressé à romeo@montague.net
  2. Le message est géré par le serveur XMPP de capulet.com
  3. Le serveur capulet.com établie une connexion avec montague.net, s'il n'en existe pas déjà une
  4. En supposant que les parents n'aient pas désactivé les communication serveur-à-serveur entre capulet.com et montague.net, le message de Juliette est envoyé vers le serveur XMPP de montague.net
  5. Le serveur montague.net voit qu'un message est adressé à un utilisateur nommé « romeo » et le fait parvenir au client XMPP tournant sur le PDA de Roméo dans le verger des Capulets.

Il y a beaucoup de choses ici : des clients tournant sur différents systèmes d'exploitation, plusieurs serveurs, un canal de communication entre les serveurs, et deux amoureux. XMPP gère tout sauf la dernière partie. Pour mémoriser le processus, visualisons le avec une image :

Fondation architecturale

Ce schéma vous semble sans doute familier, car il décrit aussi l'architecture de l'e-mail. Les communications pour les e-mails et XMPP sont rendues possibles par un réseau distribué de serveurs parlant un protocole commun. Des clients spécialisés se connectent sur les serveurs afin de recevoir les messages des autres utilisateurs ou d'en envoyer, aussi bien sur le même serveur que sur n'importe quel autre serveur connecté sur le réseau.

Néanmoins, tandis que l'e-mail est un système de stockage et de renvoi, les serveurs XMPP délivrent vos messages pratiquement en temps réel. La livraison immédiate est rendue possible par le fait que le serveur XMPP sait quand vous êtes connecté. Vos contacts le savent aussi, si vous leur donnez la permission de le savoir. La connaissance de votre disponibilité est appelée présence, et c'est la clé de voute qui permet à la messagerie d'être instantanée.

XMPP combine ces caractéristiques standards de la messagerie instantanée avec trois fonctionnalités additionnelles qui rendent la technologie unique. La première est un ensemble de protocoles ouverts, bien documentés, et faciles à comprendre. La deuxième est le fait que les protocoles sont basés à 100% sur XML, ce qui permet une messagerie structurée aussi bien entre des utilisateurs que des applications logiciels. La troisième est que XMPP utilise des adresses qui sont basées sur le DNS et des schémas d'URI reconnus, ce qui permet d'avoir des adresses du même genre que l'e-mail (utilisateur@machine).

Chacun de ces points clés est détaillé plus bas.

Client/Serveur

Les technologies XMPP utilisent une architecture client-serveur, et non une architecture directe en pair à pair comme font d'autres systèmes de messagerie. Cela signifie que toutes les données XMPP envoyées d'un client à un autre doivent passer par au moins un serveur XMPP. (En fait, les clients XMPP sont libres de négocier des connexions directes, par exemple pour l'envoi de fichier, mais ces connexions « out-of-band » sont d'abord négociées en utilisant l'architecture client-serveur.)

Un client XMPP se connecte à un serveur XMPP avec une connexion TCP sur le port 5222 (les serveurs se connectent entre eux avec le port 5269). Cette connexion est toujours active pendant toute la durée de la session du client sur le serveur, le client n'aura donc pas à demander au serveur s'il a reçu des messages, contrairement à un client e-mail. Tous les messages vous étant destinés sont envoyés immédiatement à votre client, tant que vous êtes connecté. Le serveur regarde si vous êtes connecté ou non, et quand vous n'êtes plus connecté il mémorise tous les messages qui vous sont destinés, et vous les envoie lorsque vous vous reconnectez.

Protocoles ouverts

Les technologies XMPP ont débuté dans la communauté open-source avec le serveur jabberd et les clients pour Windows, Mac OS, et Linux. Le travail de l'équipe XMPP a consisté entre autres à définir un protocole ouvert pour du streaming XML sur un réseau. Ce protocole continue de s'approfondir et de s'élargir. L'approfondissement vient principalement du travail effectué par le groupe de travail XMPP de l'Internet Engineering Task Force (IETF); ce groupe à formalisé le cœur du protocole de streaming XML sous le nom « Extensible Messaging and Presence Protocol », et a été approuvé par l'IETF en tant que RFC 3920 et RFC 3921. L'élargissement vient principalement du travail de la XMPP Standards Foundation qui définit des extensions au protocole de base qui offrent des fonctionnalités variées, comme les discussions à plusieurs participants, le transfert de fichiers, la découverte de services, les avatars, et encore beaucoup d'autres.

Puisque toutes les technologies XMPP utilisent un protocole ouvert, n'importe qui peut implémenter ces protocoles, et ils peuvent utiliser n'importe quelle licence. Cela a permis l'explosion du nombre de logiciels XMPP, qui peuvent être aussi bien des serveurs que des clients et aussi bien libres que propriétaires.

Format de données XML

XML est une partie intégrale des technologies XMPP. Pourquoi ? Parce que ça leur permet d'être complètement extensibles et capables de contenir presque n'importe quelle donnée structurée. Quand un client se connecte au serveur, il ouvre un flux XML unidirectionnel du client vers le serveur, et le serveur répond avec un flux unidirectionnel du serveur au client. Ainsi chaque session implique deux flux XML. Toutes les communications entre le client et le serveur passent par ces deux flux, sous la forme de petits morceaux ou « stanzas » de XML, comme le message suivant de Juliette à Roméo :

Exemple 1. Un message simple

<message from='juliette@capulet.com' to='romeo@montague.net'>
  <body>Comment vas-tu, Roméo ?</body>
</message>

Bien que beaucoup de stanzas XMPP sont simples, le format XML de XMPP peut aussi être étendu avec des namespaces XML officiels (gérés par la XMPP Standards Foundation) et des namespaces personnalisés pour des applications spécialisés. Cela fait de XMPP une plate-forme puissante pour transférer des données structurées, incluant des choses comme des appels XML-RPC et SOAP, des flux RSS, et des images SVG.

Réseau distribué

Comme nous l'avons vu, l'architecture de XMPP est faite de la même manière que celle de l'e-mail. Chaque utilisateur se connecte à un serveur « maison », qui reçoit les informations à leur place, et ces serveurs communiquent entre eux à la place des utilisateurs. Ainsi n'importe quel domaine peut avoir son serveur XMPP. Chaque serveur fonctionne indépendamment des autres, et possède sa propre liste d'utilisateurs. De plus, chaque serveur XMPP peut communiquer avec n'importe quel autre serveur XMPP accessible par Internet (si les communications serveur-à-serveur sont activées). Chaque utilisateur est associé a un serveur spécifique (en s'enregistrant avec un fournisseur de service ou avec une configuration administrative dans une entreprise), et les adresses XMPP sont de la même forme que les adresses e-mail. Le résultat est un réseau de serveurs flexible, contrôlable, et qui peut monter en charge bien mieux que les services monolithiques et centralisés utilisés par des fournisseurs de MI comme AOL, Microsoft et Yahoo.

Serveurs modulaires

Un serveur XMPP joue principalement trois rôles :

  • Gérer les connexions et les communications directement avec les clients XMPP.
  • Communiquer avec les autres serveurs XMPP.
  • Coordonner les différents composants serveurs associés avec le serveur.

Les serveurs XMPP ont été conçus pour être modulaires, avec des morceaux de code spécifiques qui gèrent les fonctionnalités comme l'enregistrement, l'authentification, la présence, les listes de contacts, le stockage des messages hors-ligne, et d'autres. En plus, les serveurs XMPP peuvent être étendus avec des composants externes, qui permettent aux administrateurs des serveurs d'ajouter des services au serveur de base, comme des passerelles vers les autres systèmes de messagerie instantanée. De tels composants peuvent introduire d'avantage de complexité dans un déploiement XMPP sans sacrifier la simplicité du serveur et sans nécessiter que ces composants soient approuvés par l'équipe de développement du serveur. Une fois de plus, la flexibilité est une considération cruciale dans la communauté XMPP.

Des clients simples

Un des principes de base du système de messagerie instantanée XMPP était qu'il devait être facile d'écrire un client (e.g., même quelque chose d'aussi simple qu'une connexion telnet). En effet, l'architecture de XMPP n'impose que très peu de restrictions aux clients. Les seules choses qu'un client XMPP doit faire sont :

  • Communiquer avec le serveur XMPP en utilisant un connexion TCP.
  • Analyser et interpréter des « stanzas » XML bien formés dans un flux XML.
  • Comprendre les types de données de base de XMPP (message, presence, et iq).

Il est préférable avec XMPP de déplacer la complexité des clients vers les serveurs. Cela permet de faire des clients relativement facile à faire (comme le témoigne la grande diversité des clients XMPP disponible aujourd'hui) et facilite la mise à jour des fonctionnalités du système (i.e., sans obliger les utilisateurs à mettre à jour leur client). Dans la pratique, beaucoup de fonctions de bas niveau des clients (e.g., interpréter le XML et comprendre les type de base de XMPP) sont gérées par des bibliothèques pour clients XMPP, permettant aux développeurs de clients de se focaliser sur l'interface utilisateur.

Un adressage basé sur des Standards

Sur le réseau XMPP, il y a beaucoup d'entités différentes qui doivent communiquer entre elles. Ces entités peuvent représenter des serveurs, des passerelles, des salons de discussions, un utilisateur XMPP, etc. Des Jabber ID sont utilisés à la fois internement et externement pour définir l'appartenance ou pour router des informations. Les caractéristiques principales des Jabber ID incluent :

  • Ils identifient de manière unique des objets individuels ou des entités pour échanger des messages ou des informations de présence.
  • Ils sont faciles à retenir et à transmettre dans le monde réel pour les utilisateurs.
  • Ils sont suffisamment flexibles pour permettre l'inclusion d'autres MI ou de schémas de présence.

Chaque identifiant Jabber (ou « JID ») contient un ensemble de données ordonnées. Les JID sont formés d'un domaine, d'un nœud et d'une ressource dans le format suivant :

   [nœud@]domaine[/ressource]

Les éléments du JID sont définis comme suit :

  • L'identifiant du Domaine est l'identifiant primaire. Il représente le serveur XMPP auquel l'entité de connecte. Tout domaine XMPP utilisable devrait être un nom de domaine entièrement défini.
  • L'identifiant du Nœud est l'identifiant secondaire. Il représente « utilisateur ». Tout les nœuds sont rattachés a un domaine spécifique. Toutefois, l'identifiant du Nœud est optionnel, et un domaine spécifique (e.g. conference.jabber.org) est un Jabber ID valide.
  • L'identifiant de Ressource est l'identifiant tertiaire, il est optionnel. Toutes les ressources appartiennent à un Nœud. Dans XMPP l'identifiant de Ressource identifie un objet spécifique appartenant à l'utilisateur, comme un appareil ou un lieu. Les Ressources permettent a un utilisateur unique d'avoir plusieurs connexions simultanées avec le même serveur XMPP ; par exemple juliette@capulet.com/balcon et juliette@capulet.com/chambre.

Un utilisateur XMPP se connecte toujours à un serveur en utilisant une ressource particulière et a donc une adresse de la forme noeud@domaine/ressource lorsqu'il est connecté (e.g., juliette@capulet.com/balcon). Toutefois, comme une ressource est spécifique à une session, l'adresse de l'utilisateur peut être communiqué sous la forme noeud@domaine (e.g., juliette@capulet.com), ce qui est familier pour les gens car c'est la même forme qu'une adresse e-mail.

Conclusion

Les protocoles et technologies XMPP fournissent une véritable alternative ouverte aux services fermés et propriétaires offerts par les anciens fournisseurs de MI comme AIM et MSN. La standardisation IETF de XMPP et la base XML permettent aux développeurs de créer une solution robuste, presque temps réelle de messagerie et de présence pour la MI et encore plus. Rejoignez la conversation, visitez http://xmpp.org/.