Autheur : Peter Saint-André
Présentation : Jean-Pierre Lessard
Date : 16-Janvier-2003
Vesion : 1.0.0
Corrections : [email protected]
Jabber est un système de Messagerie Instantané comme ICQ ou AIM.
Il est open source, simple, rapide, extensible, modulaire, multi- plateformes, et créé avec le soucis des technologies futures. Jabber a été conçu depuis le départ pour servir les besoins de l'utilisateur final, des entreprises, et maintenir la compatibilité avec les autres systèmes de messagerie.
Jabber est beaucoup de choses à la fois. Certains pensent que c'est seulement le nom du logiciel client qu'ils utilisent, c'est à dire : "WinJab" ou "Gabber" (les deux clients qui me servent d'exemples dans ce guide).Mais derrière ces clients, existe aussi le serveur sur lequel vous vous connectez afin de discuter avec d'autrespersonnes (souvent avec des gens connectés sur d'autres serveurs fonctionnant dans une autre partie du réseaude Jabber). Et derrière ces serveurs et ces réseaux existe un ensemble de protocoles open-source, en XML,permettant la circulation de messages structurés, décrivant la présence et tous les autres éléments requis pourpouvoir s'enregistrer, ouvrir une session, discuter, et ainsi de suite.
Pourquoi devriez-vous vous inquiéter ? Ok, peut-être que, vous ne devriez pas. Peut-être que, tout ce quevous voulez faire, c'est simplement pouvoir discuter avec vos amis en utilisant AIM, ICQ, MSN, ou Yahoo.Peut-être que ça ne vous intéresse pas de savoir comment tout cela fonctionne. Peut-être que vous ne voussouciez pas des protocoles standards comme le XML, ou l'open-source. Peut-être que c'est sans importancepour vous, si les grands systèmes de Messageries-Instantanées maintiennent leurs utilisateurs séparés les unsdes autres, vous forçant à employer quatre clients différents. Peut-être aussi, que c'est la seule chose qui vousintéresse avec Jabber : l'interopérabilité.
Je ne veux pas vous effrayer, mais je voudrais vous demander ceci : si vous êtes d'accord avec ça (peut-être),alors il est possible que Jabber ne soit pas vraiment fait pour vous. Jabber est un système puissant, mais si ceque vous recherchez, c'est seulement "l'interopérabilité", alors vous pourriez préférer utiliser Trillian, GAIM, ou un autre client de MI quelconque.
Mais si vous êtes curieux, si vous aimez l'idée du logiciel open-source, si vous préférez soutenir lesprotocoles ouverts a la place des systèmes propriétaires, si vous voulez participer à l'existence d'un réseauvéritablement ouvert, qui permet la liberté de communication, et qui ne traite pas l'individu comme étant unepaire de globes oculaires, alors peut-être, peut être que Jabber est vraiment ce que vous recherchez.
Comme je l'ai laissé entendre, Jabber est un logiciel formidable, mais il n'est pas toujours facile à utiliser.Pour éviter toute confusion, il est important d'en savoir un peu plus sur son principe de fonctionnement.J'aime Shakespeare, imaginons donc deux personnages de Shakespeare, et comment ils échangent leurs messages (Juliette est en haut, sur le balcon, et Roméo en bas, dans le jardin). Juliette n'envoie pas un messagedirectement à Roméo, du moins pas dans le monde de Jabber. Juliette a un compte sur un serveur Jabber.
Ce compte (nous l'appelons un "JID") ressemble beaucoup à une adresse E-Mail. Puisque Juliette est uneCapulet, elle enregistre l'username : juliette sur le serveur Jabber fonctionnant chez capulet.com. Ainsi sonJID sera [email protected]. De même, Roméo a un compte sur le serveur de sa famille et son JID [email protected] fois que Juliette est référencée sur le serveur de capulet.com, elle peut envoyer des messages à sonamoureux. Voici ce qui se produit réellement quand Juliette envoie un message avec WinJab du haut de sonbalcon :
1. Juliette envoie un message adressé à [email protected].
2. Le message est récuperé par le serveur Jabber chez capulet.com.
3. capulet.com ouvre une connexion avec montague.net.
En supposant que les aînés des deux familles n'aient pas bloqué les communications de serveur à serveur entre capulet.com et montague.net, le message de Juliette est dirigé vers le serveur Jabber chezmontague.net
4. Le serveur montague.net voit que le message est adressé à un utilisateur existant appelé romeo et ill'expedis aussitôt au client Jabber de Roméo (Gabber) qui tourne sur son desktop Linux, dehors, dans le jardin.
5. Le message apparaît dans une fenêtre Gabber.
6. Il y a ici, beaucoup de processus en cours : des clients fonctionnant sur différents systèmes d'exploitation, desserveurs multiples, une voie de transmission entre les serveurs, et également des sentiments qui lient lesamoureux. Ceci mis a part, Jabber peut tout manipuler, et chaque maillon de cette chaîne, offre un largeéchantillon de choix. Ainsi, commençons par choisir un client Jabber.
Le choix d'un client Jabber dépend de votre système d'exploitation, de vos besoins, et dans une certainemesure de votre expérience antérieure avec d'autres systèmes de MI. Quelques clients sont plus aboutis qued'autres, certains offre plus de fonctionnalitées, d'autres ressemblent plus a AIM ou ICQ ou MSN, et ainsi desuite. A mon humble avis, la plupart des concepteurs de Jabber tendent à conseiller WinJab pour Windows etGabber pour Linux, bien qu'il existe beaucoup d'autres clients Jabber (il y en a une longue liste chez JabberCentral).
Dans ce guide, je me concentre essentiellement sur les clients "WinJab" et "Gabber". D'abord parce qu'ils sontles plus anciens et aussi parceque ce sont ceux que je connais le mieux. Cela ne signifie pas que je n'aime pasvotre client préféré. J'ai dû me concentrer dans ce guide sur un ou deux clients, ou bien je ne l'aurais jamaismis à jour !
Une fois que vous aurez arrêté votre choix, suivez la procédure d'installation et lancez le programme pourpouvoir choisir un serveur Jabber.
Exemples :
Afin de pouvoir utiliser Jabber, vous devez vous créer un compte sur un serveur Jabber (c'est comme de vouscréer un compte chez un fournisseur d'accès internet ou de configurer votre client mail pour pouvoir vousconnecter au serveur mail de votre entreprise). Comme pour les clients Jabber, le choix du meilleur serveurdépend de vos besoins (par exemple, vous pouvez très bien utiliser le serveur Jabber de votre entreprise). Leserveur public initial de Jabber se trouve chez jabber.org. C'est un bon choix et c'est aussi celui que j'utilise,mais il existe beaucoup d'autres serveurs publics (vous en trouverez une liste chez JabberView). Bien sûr,l'accès à ces serveurs est gratuit.
Une fois que vous avez choisi un serveur Jabber, la prochaine étape consiste à vous créer un compte.
Note: Les paquets de Jabber transitent sur le port 5222. Si vous êtes derrière un pare-feu, vous ne pourrezpas utiliser un client Jabber classique. Essayez le WebClient de jabber.com, si vous ne pouvez pas obtenirl'autorisation de passage a travers le pare-feu.
C'est une opération très simple : Il vous suffit d'ouvrir une session avec "l'Username" et le "Password" devotre choix. Si cela ne fonctionne pas du premier coup, ressayer.
Voici comment faire : Quand vous ouvrez WinJab ou Gabber, apparaît un écran de connexion.
Complétez l'information concernant le "Server" (par exemple capulet.com ), le "Username" (par exemplejuliette), et le "Password" (par exemple R0m30). Le menu déroulant "Resource" permet d'intégrer desinformations vous concernant (si vous avez des clients Jabber installés sur plusieurs ordinateurs), vous pouvezindiquer le lieu d'ou vous envoyez vos messages (par exemple le balcon) ou le nom du programme (parexemple WinJab).
Cliquez sur "Ok" ou "Login" selon votre client Jabber, et celui-ci essayera d'ouvrir une session sur le serveurque vous lui avez indiqué.
Si votre "Username" est déjà pris par quelqu'un d'autre, vous serez invités à en essayer un autre.
S'il ne l'est pas (chaque "Username" doit être unique), votre client Jabber vous demandera de confirmer lacréation de votre compte.
Le meilleur moyen de vérifier si votre compte fonctionne bien est de Contacter quelqu'un.
C'est la partie du guide où j'avais l'habitude de proposer que vous m'envoyiez un message à titre d'essai.
Malheureusement, la quantité de messages obtenue était trop importante, même pour un fanatique de Jabbercomme moi !
La solution a donc été d'écrire un petit BOT (sorte de personnage virtuel) qui vous permettra d'envoyer unmessage d'essai et de recevoir une réponse. Pour le moment ce BOT est assez stupide (il renvoi toujours lemême message). Mais il est en ligne plus souvent que moi, et cela vous garantit presque un essai réussi.
Envoyez un nouveau message en sélectionnant le menu WinJab > Send Message (pour WinJab) ou (pour Gabber) Services > New Blank Message. Vous verrez la fenêtre suivante :
Dans le "JID", écrivez [email protected]. Composer ensuite votre message et cliquer sur le bouton"Send". (le sujet est facultatif). Si mon BOT fonctionne, vous recevrez presque immédiatement une réponse.
Une des nombreuses fonctionnalités de Jabber est de pouvoir participer à une discussion de groupe (appelés"groupchat"). Il n'y a pas de limite aux "chatrooms" que vous pouvez créer sur votre serveur (celui sur lequelvous êtes enregistré). Vous pouvez également rejoindre des "chatrooms" créés sur d'autres serveurs, ailleurssur le réseau de Jabber.
L'IRC est le "Internet Relay Chat" : le protocole original de "chat" sur Internet. Bien que l'IRC ait seslimitations, c'est toujours une manière très populaire de discuter en temp réel on-line (par exemple, lesprogrammeurs de Jabber se réunissent régulièrement sur le canal #jabber disponible surirc.openprojects.net, ou sur irc.linux.org, et aussi sur d'autres serveurs).
Avec Jabber et son protocole IRC, vous n'avez pas besoin d'utiliser un autre client IRC. Vous allez pouvoir continuer à discuter sur vos canaux favoris avec le même logiciel ! Voici comment se connecter sur l'IRC avec WinJab (votre serveur Jabber doit supporter le protocole IRC. Consulter JabberView si vous avez un doute).
Bien sûr, vous n'allez pas forcément connaître l'adresse Jabber (le JID) d'une personne que vous souhaitezcontacter. Aussi, la question se pose naturellement : comment allez-vous trouvez vos amis avec Jabber ?
Jabber a son propre annuaire d'utilisateur. Il contient les informations de base les concernant (il s'appelle le"Jabber User Directory" ou bien JUD). Vous pouvez l'interroger en sélectionnant le menu Roster >Search for User ou par un Crtl-F. Choisissez alors dans la liste déroulante Search Via, l'option Jabber User Directory.
Pour savoir si un ami est disponible, Jabber vous permet de voir "la présence" de cette personne (qui peut êtreen ligne, partie, etc...). Pour cela, vous devez souscrire à un "abonnement" chez cette personne, et celle-ci doitl'accepter. Pour protéger l'intimité des utilisateurs de Jabber, il doit y avoir un accord mutuel pour avoir ledroit de voir la présence de chacun. C'est un peu comme une poignée de main dans la vraie vie. Voici ce quise produit :
1. Vous recevez une demande d'abonnement à votre présence :
2. Vous pouvez accepter ou rejeter cette demande d'abonnement, en cochant ou décochant la case"Allow this person to see my presence" (permettez à cette personne de voir ma présence).
3. Si vous acceptez et cliquez sur le bouton "Ok", l'autre personne verra une fenêtre comme celle-ci (très semblable à celle que vous venez de recevoir).
4. La "Poignée de Main" est complète, et vous êtes tous les deux abonnés à la présence en ligne dechacun. Maintenant, toutes les fois que votre ami sera en ligne, vous verrez une ampoule jaune à côtéde son nom, dans votre liste de contacts. S'il a placé son nivaux de disponibilité sur "ne pas déranger",vous verrez un tiret rouge, et s'il est hors ligne, vous verrez une ampoule grise.
Bien sûr, vous pouvez à tout moment annuler l'abonnement d'un contact, et ainsi contrôler votre "visibilité".Maintenant, d'un simple double clique sur son nom, vous pouvez contacter cette personne. Si elle est présente(ampoule jaune), une fenêtre de "chat" s'ouvre et vous pouvez commencer à discuter. Si elle estmomentanément absente (ampoule grise), c'est une fenêtre de message qui s'ouvre, écrivez votre message, etelle le lira lors de sa prochaine reconnection.
La première application de la technologie Jabber est un système de messagerie instantanée et de présence qui a été conçu et continue à être développé par la communauté open-source. Jabber se distingue des autres système de MI existants sur plusieurs points :
Basé sur XMLRéseau distribuéProtocole et logiciels open-sourceArchitecture modulaire et extensible
Ce document fournit une vue d'ensemble de l'architecture de Jabber, il se concentre particulièrement sur la conception du serveur, qui en est maintenant à la version 1.4.
Jabber a été conçu dans une large mesure sur le modèle du système de transmission de messages le plus réussi d'Internet, c'est a dire : l'E-mail. Les communications s'établissent au travers d'un réseau distribué de serveurs qui emploient un protocole commun. Les clients se connectent sur ce réseau pour pouvoir envoyer et recevoir des messages des autres utilisateurs.
Alors que l'E-mail est un système de transfert et d'enregistrement de messages, Jabber lui, transfert des messages instantanés. Les serveurs Jabber (et, par extention, les autres utilisateurs de Jabber) savent en permanence lorsqu'une personne particuliere est en ligne. Cette information de disponibilité, s'appelle "la présence" et est l'élément essentiel de tout systeme de messagerie instantanée.
Jabber combine cette caractéristiques de MI standard avec deux autres caractéristiques qui rendent Jabber unique. La premiere est un protocole ouvert qui permet l'interopérabilité avec les autres systèmes de MI. La seconde est un protocole basé sur XML, cela rend possible la communication non seulement entre des utilisateurs humains, mais également entre des applications logiciel.
Jabber s'appuie sur une architecture de type client/serveur, et non de type client/client comme le font d'autres systèmes de MI. Cela signifie que tous les messages et données qui transitent d'un client vers un autre, passent par un ou plusieurs serveurs. N'importe quel client peut ensuite négocier une connexion directe avec un autre client, mais ces connexions sont spécifiques à certains besoins, comme par exemple pour le transfert de fichiers. Ces connexions particulières sont néanmoins initialisées dans le contexte de l'architecture client/serveur de Jabber.
Le réseau Jabber est bâti sur le modèle de l'E-mail. Donc, chaque utilisateur dispose de son serveur local de qui il reçoit toutes les informations, et les serveurs se transfèrent entre eux les différents messages et informations de présences. Il peut exister, toutes sortes de serveurs Jabber acceptant ou non les communications avec d'autres clients connectés sur d'autres serveurs. Chaque serveur fonctionne indépendamment des autres, et maintient sa propre liste d'utilisateurs. N'importe quel serveur Jabber peut communiquer avec n'importe quel autre serveur pourvu qu'il soit connecté sur Internet.
Un utilisateur particulier est associé à un serveur particulier qui peut être public ou privé (comme par exemple au sein d'une entreprise). Les adresses Jabber sont de la même forme que les adresses E-mail, par exemple : [email protected]. Les adresses Jabber sont détaillées ici.
Le serveur Jabber joue deux rôles principaux :
1- Ecoute des connexions et communications avec les clients logiciels.
2- Communication avec d'autres serveurs Jabber.
Le serveur Jabber est modulaire, chaque module gère des fonctionnalités telles que l'authentification utilisateur, le stockage de données (messages, préférences, messages en attentes), et autres. En outre, le serveur peut être étendu par des services additionnels, tels que la sécurité intégrée, les connexions avec des clients alternatifs, et les passerelles vers d'autres systèmes de MI.
L'échange de messages et d'information de présence entre Jabber et un autre système de MI non-Jabber, donne un bon exemple de cette modularitée. Ce type de communication est rendu possible grâce à une couche de "transport" indépendante, qui traduit les flux XML de Jabber en protocole étranger. Cette couche "transport" ne fait pas partie du noyau du serveur. Au lieu de cela, ce sont des programmes modulaires qui peuvent être ajoutés facilement au serveur pour fournir la fonctionnalité demandée.
Un des critères de conception du système Jabber était qu'il puisse supporter des clients simples (quelque chose d'aussi simple par exemple, qu'une connexion Telnet). En effet, l'architecture de Jabber impose très peu de restrictions aux clients. Les seuls dispositifs qu'un client doit pouvoir supporter sont :
- Communiquer avec le serveur Jabber grâce à des sockets TCP.
- Analyser et interpréter des paquets XML bien formés.
- Distinguer les différents types de données et messages.
Le choix de conception de Jabber a été de déplacer la complexité des clients vers le serveur.
Ceci permet d'écrire des clients, relativement facilement, (noter la grande variété disponible de clients Jabber) mais aussi d'ajouter de nouvelles fonctionnalités au système, sans obliger les utilisateurs à installer de nouveaux logiciels clients. Les clients Jabber communiquent avec le serveur grâce à des flux XML, encapsulés dans des sockets TCP, sur le port 5222, et ne communiquent pas directement entre eux. Dans la pratique, plusieurs des fonctions de bas niveau du client (par exemple, l'analyse XML et la compréhension des balises Jabber, comme : <message/>, <presence/>, et <iq/>) sont manipulées par des bibliothèques, cela permet aux programmeurs de clients, de se concentrer sur l'interface utilisateur.
XML est une caractéristique essentielle du système Jabber. Il est très important que l'architecture soit fondamentalement extensible et puisse contenir toutes sortes de données structurées. (plus spécifiquement, Jabber utilise des flux XML pour la communication avec le serveur, et de serveur à serveur. Le flux de paquets XML est toujours initialisé par le client vers le serveur, et la "vie" du flux XML est directement associée à la durée de la session de cet utilisateur.)
Bien que Jabber soit fortement lié à XML, il est en même temps, indépendant du média de livraison :
il n'y a aucune restriction inhérente au système de livraison, et aucune connaissance dans l'architecture du système de livraison n'est nécessaire. Cela doit permettre, entre autres, de bâtir un système de communication qui puisse rendre transparent l'échange de messages avec des services tiers (comme par exemple : IRC, ICQ, AIM).
Le serveur Jabber se compose de modules multiples qui gèrent les différentes fonctions du système.
Au coeur des modules du serveur, quatre composants ont pour unique fonction de diriger et de livrer les paquets XML d'un composant de bas niveau à un autre. Ces quatre composants sont : accept, connect, exec, et load. Chacun de ces composants de base, décode en entrée le paquet XML, le livre aux autres composants qui le réencodent en XML à destination des composants de plus bas nivaux. Voici un schéma de l'architecture :
Lors du démarrage du serveur, les modules sont chargés selon leurs degrés de priorité par rapport au noyau (ces degrés sont définis dans le fichier de configuration), les modules manipulent ensuite les données selon ces priorités (définissant de cette manière, la logique de livraison).
Le noyau du serveur Jabber, grâce aux modules, gère les tâches courantes suivantes :
- Gestion de sessions.
- Communication de client/serveur.
- Communication de serveur/serveur.
- Résolution DNS.
- Authentification des utilisateurs.
- Enregistrement de nouveaux utilisateurs.
- Consultations de base de données.
- Stockage des messages destinés à des utilisateurs absents.
- Stockage et recherche des "vCards".
- Filtrage d'informations basés sur des "préférences utilisateur".
- Discussion de groupe (communication multiple).
- Notes système.
De plus, le noyau du serveur peut être étendu par des modules additionnels capables de gérer différents protocoles non-Jabber. Actuellement, les protocoles supportés sont les suivants :
- AOL Instant Messenger (AIM)
- ICQ
- Internet Relay Chat (IRC)
- MSN Messenger
- Rich Site Summary (RSS 0.9)
- Yahoo! Messager
NOTE : d'autres modules de transports seront intégrés au fur et à mesure de leurs créations, comme par exemple, le module qui gérera le futur protocole de l'IMUnified.
Suivre le cheminement d'un message au sein du serveur Jabber, est, une bonne introduction à son architecture.
Bien que l'élément XML <message> soit seulement l'un des trois éléments principaux du protocole de Jabber, il en est l'élément essentiel : c'est lui qui transporte l'information d'un point à un autre.
Voici un diagramme de ce flux :
Le serveur Jabber (ici nommé "jabberd", abréviation le "démon Jabber") attend des paquets de type <message> contenu dans une socket TCP sur le port 5222 (ou sur le port 5223 si le SSL est autorisé et en service).
Si une session n'existe pas, le "jabberd" lancera la procédure d'authentification.
Si une session existe, les paquets seront envoyés au "Jabber Session Manager" (JSM).
Voici un exemple de paquet XML :
<message
to='[email protected]'
type='chat'>
<body>Hey, the AIM transport is working great!</body>
</message>
Ensuite, le JSM vérifie le "hostname" du serveur de destination dans la liste de noms de serveurs contenus dans son fichier de configuration. Souvent cet "hostname" y sera défini. Par exemple, aim.jabber.org est défini dans le fichier de configuration du serveur jabber.com pour se diriger vers le module de transport de AIM (qui pourrait être sur une autre machine). Si cet "hostname" n'est pas défini dans le dossier de configuration, le composant "dnsrv" devra "résoudre" cet "hostname", composé d'une adresse IP et d'un port.
De l'une ou de l'autre manière, le paquet message sera ensuite expédié au composant de communication de serveur-à-serveur (le "s2s") puis au serveur concerné, qui sera dans notre exemple : jabber.org.
Le module "s2s" expédiera donc le message au serveur ou à un module de transport de ce serveur.
Dans notre exemple, la destination exacte du paquet message est : aim.jabber.org, donc le paquet sera envoyé au module de transport AIM sur jabber.org pour être finalement transmis à un utilisateur d'AOL
Dans tout les cas, le message a transité d'un client vers un serveur, puis vers un autre serveur ou vers un autre systeme de MI.
Comme mentionné précédemment à propos des flux de paquets, les messages et les informations de présence transitent dans le contexte d'une architecture client/serveur. Dans le protocole Jabber, cette session est initialisée au moyen de deux flux XML. L'un allant du client vers le serveur et l'autre du serveur vers le client. Voici un exemple de flux XML lors d'une ouverture de session :
SEND:<stream:stream
SEND:to='jabber.org'
SEND:xmlns='jabber:client'
SEND:xmlns:stream='http://etherx.jabber.org/streams'>
RECV:<stream:stream
RECV:xmlns:stream='http://etherx.jabber.org/streams'
RECV:id='39ABA7D2'
RECV:xmlns='jabber:client'
RECV:from='jabber.org'>
SEND:<iq id='1' type='set'>
SEND:<query xmlns='jabber:iq:auth'>
SEND:<username>stpeter</username>
SEND:<resource>Gabber</resource>
SEND:<digest>f1e881517e9917bb815fed112d81d32b4e4b3aed</digest>
SEND:</query>
SEND:</iq>
RECV:<iq id='6' type='result'/>
(XML for user session goes here)
SEND:</stream:stream>
RECV:</stream:stream>
Cependant, pour que le serveur puisse ouvrir une session, il doit auparavant authentifier l'utilisateur.
Le schéma suivant décrit, le flux des paquets nécessaires à l'authentification :
La procédure d'authentification démarre lorsque le client se connecte au serveur et lui envoi un paquet XML.
Immédiatement, les modules de contrôles du serveur se mettent dans l'attente d'un paquet de type <iq> (abréviation de info/query) contenant un sous- élément <query> possédant un attribut de type : xmlns="jabber:iq:auth".
Ce paquet XML, devra contenir les informations d'authentification de l'utilisateur, ou le cas échéant, les données nécessaires a l'enregistrement d'un nouveau compte pour cet utilisateur. Ces informations se composent d'un nom (ou "login") et d'un mot de passe, le mot de passe est crypté grâce à l'algorithme SHA1 (ceci correspond au schéma d'authentification standard).
Dés que cette information est reçue, le parseur XML passe la main au "deliver", qui commencera à surveiller le tampon d'entrée au cas où le client continuerait à envoyer des paquets sans avoir été parfaitement authentifier.
Le serveur (généralement le JSM) passera alors le paquet d'authentification au composant "xdb".
Le composant "xdb" (moteur de base de données Xml) enverra le paquet aux autres sous-composant abonnés à ce type de paquet : par exemple, la correspondance des paquets d'authentification décryptés pourrait être recherchée dans le système de fichier XML en utilisant le sous-composant "xbd_file", tandis que la correspondance des paquets d'authentification crypté pourraient être recherchée dans le LDAP en utilisant le sous-composant "xdb_ldap".
Le rôle du JSM se limite juste à transmettre le paquet d'authentification au composant "xdb", qui se chargera lui-même de l'envoyer au sous-composant approprié. De plus, pour accélérer la rapidité d'exécution, le composant "xdb_ldap" possède sa propre réserve de threads.
Le composant "xdb" retournera le résultat de la requête d'authentification au serveur (le JSM).
Si l'authentification échoue, le serveur renverra au client le code d'erreur 401 et n'ouvrira pas de session.
Si l'authentification réussie, le JSM ouvrira une session (et libérera le "delivrer"). Désormais, tous les paquets "presence", "message", et "iq", transiteront dans le cadre de cette session ; Jusqu'à ce que le client ou le serveur termine la session en envoyant une balise de flux fermante : </stream>.
Voici le schéma d'activité du JSM :
Comme mentionné, le "JSM" gère les paquets de type message, présence, et IQ, d'un client connecté au serveur.
Cependant, le JSM manipulera également les paquets destinés à un utilisateur momentanément absent. Par exemple, imaginons que vous m'envoyez un message ([email protected]) et que je ne sois pas en ligne. Le JSM devra stocker ce message sur le serveur jusqu'à ce que je sois de nouveau en ligne.
Le JSM distingue les utilisateurs en ligne et hors ligne en se basant sur la "ressource" de l'adresse du paquet XML (la "ressource" est le dispositif, le logiciel client, ou l'endroit d'où vous vous connectez.
Par exemples : "laptop", "Gabber", ou "à la maison"). Normalement, un utilisateur est absent si le paquet XML ne contient pas de ressource. Cependant, il arrive parfois que la ressource soit absente par erreur, alors, le JSM vérifie si l'utilisateur est réellement hors ligne avant d'envoyer le paquet au module "d'absence", qui pourrait (par exemple) stocker le message ou rechercher une "vCard".
Si l'utilisateur est en ligne, le message, l'information de présence, ou le paquet "iq" n'est pas envoyé au module "d'absence" mais est géré par le JSM. Un tel paquet ne peut avoir que deux états possibles : ou il doit être livré à l'utilisateur ou il est envoyé par l'utilisateur. Ainsi le JSM possède deux contrôleurs en attente des paquets "to" ou "from" de l'utilisateur, puis les dirige vers le module approprié. Une fois que le module a manipulé le paquet, il est a nouveau retourné aux contrôleurs pour une autre manipulation par d'autres composant ou, si tout le traitement est achevé, l'expédier à/de l'utilisateur.
Voici un exemple : imaginons que je reçoive un message de [email protected]. Je suis en ligne, donc le message est envoyé au JSM. Le contrôleur stoppe ce paquet qui m'est destiné, et envoie un appel aux modules qui sont abonnés au JSM. Le premier module a répondre, est un "mod_filter" qui trie les messages entrants selon des critères définis par l'utilisateur. Dans ce cas-ci (puisque je n'ai semble-t-il jamais obtenu de critiques désagréable de notre ami foobar), j'ai configuré le "mod_filter" pour rediriger tous les messages venant de [email protected] dans ma boîte aux lettre en utilisant le protocole smtp (en cours de réalisation). Donc le "mod_filter" restructure le message de telle sorte que l'adresse de destination initialement jabber.org devienne maintenant smtp.jabber.org, puis réexpédit le paquet au contrôleur. Un nouvel appel est fait aux autres modules abonnés au JSM, mais comme aucun d'eux ne répond, le paquet est finalement expédié a [email protected], où le message sera directement transféré dans ma boite aux lettre.
Ce qu'il est important de noter, c'est que ce processus est itératif, c'est a dire que de multiples modules peuvent manipuler un paquet avant qu'il soit finalement envoyé à/de l'utilisateur. Ceci donne au JSM beaucoup de flexibilité et d'extensibilité, puisque la nouvelle fonctionnalité peut être ajoutée au serveur en lui rajoutant un module sans avoir à modifier le JSM ou les modules existants.
Le JSM utilise les threads (processus) multiples pour accélérer l'exécution des tâches.
Lors du démarrage du serveur, un certain nombre de threads sont assignés à la réserves de threads (ce nombre est défini dans le fichier de configuration). Lorsque que des paquets de messages sont transmis au JSM par le module d'entrée, le JSM extrait dynamiquement des threads inutilisés de la réserve et les affecte aux ports d'entrée et de sortie de messages. (Le "port de message" est une structure de donnée qui gère une connexion avec un client.) Si aucun thread n'est disponible dans la réserve, le JSM peut (mais n'est pas obligé) créer un nouveau thread et l'associer au port de message approprié.
Voici un schéma du processus :
Le module de livraison est le coeur du serveur, puisqu'il est chargé de transporter les données d'un composant bas vers un autre.
Voici le schéma du système de transfert des données à ce niveau :
Une fois qu'un paquet est livré à l'un des composants bas (accep, connect, exec, ou load), il peut être envoyé à un sous-composant tel que le "jpolld" ou le "xdb_ldap" pour une transformation ultérieure.
Un exemple de condition préalable pourrait être le résultat d'une interrogation "xdb" (obtenu d'une base de données).
Un exemple d'état de processus pourrait être l'addition d'un "namespace" de destination qui sera utilisé par le JSM, et un exemple de transformation de paquet pourrait être un changement de format de message avant livraison en transformant l'adresse de destination.
Bien que le but principal du projet Jabber soit la réalisation d'un système de messagerie instantanée robuste basé sur XML, un second objectif important est l'interopérabilité entre les différents systèmes de MI existants.
Fondamentalement, le projet de Jabber y contribue en rendant son protocole complètement ouvert. Cependant, il y contribue également en permettant la communication entre le format XML de Jabber et les nombreux autres formats non-Jabber par l'utilisation de ce qui dans le monde de Jabber s'appelle une couche "transport".
Quand un utilisateur de Jabber envoie un message à un utilisateur d'un système étranger, l'adresse de livraison de ce message contient les éléments du transport. Le client Jabber de l'utilisateur envoie son message au module dédié au protocole étranger, accompagné d'une identification Jabber qui contient le nom du système étranger (par exemple, [email protected]). Le serveur Jabber expédie alors les données au module de transport approprié. Si le module de transport est local (tournant sur la même machine), le JSM le transfère directement, si le module de transport fonctionne à distance (sur une autre machine), alors le serveur local passe le paquet au serveur distant; qui le passera lui-même au module approprié. Une fois que le module reçoit le paquet XML, il "transforme" le message (ou des instructions) en paquet étranger, compréhensible par l'autre réseau de MI, et le serveur l'expédie sur ce réseau.
Voici un schéma général de la couche transports de Jabber :
Essentiellement, un module de transport met en application un modèle de procuration. La plupart des modules de transports contiennent leur propre petit JSM, dans lequel sera traduit le XML de Jabber en protocole "étranger" pour la présence, les messages, et l'interrogation "iq". En général, le module de transport affecte un thread par utilisateur pour gérer ses communications.
Dans certains cas la traduction du protocole de Jabber est assez facile, par exemple lorsque le protocole étranger est bien documenté (ex : IRC ou AIM). Dans d'autres cas, la traduction est rendue plus difficile par la nature propriétaire ou non documentée du protocole étranger (ex : Yahoo). On peut espérer que l'initiative d'IMUnified (http://www.imunified.org) parvienne a ouvrir certains protocoles aujourd'hui fermés, ou parvienne a créer un protocole commun.
Bien que la plupart des modules de transports servent à communiquer avec des services non-Jabber, il y a des exceptions à cette règle. Par exemple, le module de "Groupchat" permet de dialoguer avec plusieurs autres utilisateurs dans une salle de discutions, comme le protocole IRC. Ce module "Groupchat" sert de serveur de réflexion à tous les utilisateurs connectés, en renvoyant chaque nouveau message reçu à tous les autres membres. Il créera et détruira également les salles selon les besoins. C'est à dire, que si je rejoins une salle qui n'existe pas, le module créera cette salle, et si je suis la dernière personne à quitter une salle, le module se chargera de la détruire. Une salle est désignée comme ceci : groupname@groupchatserver, et chaque participant est identifié par une ressource unique représentant son surnom. Par exemple, le "groupchat" des sorcières dans Macbeth de Shakespeare pourrait avoir lieu dans une salle dont l'adresse est [email protected], et les sorcières pourraient être identifiées comme [email protected]/firstwitch et ainsi de suite.
Voici ce qu'elles pourraient voir :
Une entité de Jabber peut s'abonner à la présence de n'importe quelle autre entité (c'est a dire, a une "Jabber ID").Un abonnement est essentiellement un accord de l'utilisateur a qui est faite la demande d'abonnement, d'envoyer ses informations de présences a l'abonné. Cet accord est stocké dans les préférences de l'utilisateur.
Quand je m'authentifie et crée une session sur le serveur, mon information de présence est stockée par le JSM.
A chaque fois que mes informations de présences changent, le serveur consulte mes préférences, et expédie les informations de présence à toutes les entités Jabber qui sont abonnées à ma présence.
Voici les différentes relations de présences possibles, stockées dans les préférences utilisateurs :
1- to -- Cette entité vous envoie ses informations de présence.
2- from -- Cette entité reçoit vos informations de présence.
3- both -- Vous vous envoyez et recevez vos informations de présence respectives.
4- none -- Ni vous ni l'autre entité n'envoyez ni ne recevez les informations de présence de l'autre.
L'entité envoyant ses informations de présence n'est pas forcement un autre utilisateur Jabber, mais peut être un service extérieur tel qu'une source de données ou un système de MI non-Jabber. Dans ce dernier cas, les abonnements aux utilisateurs du système non- Jabber sont gérés par le module de transport, et l'utilisateur Jabber s'inscrit au module de transport correspondant (par exemple, icq.jabber.org). Une fois que l'utilisateur Jabber s'est enregistré avec succès, chaque changement de présences du propriétaire provoque envoi d'une demande d'information de présence au module. Un paquet de présence spécial est envoyé avec l'attribut "from" produit par le module, avec les données correspondantes du protocole étranger.
Le serveur Jabber maintient une liste des abonnements de chaque utilisateur (par exemple, dans une base de données).
Cette liste nommée "liste de contacts" est semblable à ce qui dans d'autres systèmes de MI s'appelle une "liste de copain". Les préférences dans Jabber sont stockées sur le serveur et sont ainsi disponible de n'importe ou sur le réseau. Le serveur Jabber gère automatiquement les préférences selon les différents types d'abonnement.
Les préférences, peuvent également contenir d'autres informations, comme par exemple les "nicknames" de cet utilisateur ou les "groupe" auxquels il appartient. Ces informations peuvent être exploitées par le logiciel client pour les présenter dans une interface appropriée.
Dans Jabber il y a beaucoup de différentes entités qui doivent communiquer entre elles.
Ces entités peuvent représenter des modules de transports, des salles de "groupchat", ou bien, un simple utilisateur Jabber. Des identifications Jabber sont employées extérieurement et expriment intérieurement les informations de propriété ou de cheminement. Voici les principales caractéristiques des identifications Jabber :
1- Ils identifient de façon unique les différents objets et entités nécessaires aux expéditions de messages et d'informations de présences.
2 -Ils sont facilement mémorisables par des utilisateurs humains.
3 -Ils sont assez flexibles pour permettre d'encapsuler d'autres protocoles de MI.
Chaque identification Jabber (ou "JID") contient un ensemble d'éléments. Les JID sont constitués d'un domaine, d'un noeud, et d'une ressource dans le format suivant :
node@domain/resource
Les éléments d'identification de Jabber sont définis comme suit :
1- Le "Domain Name" est la marque primaire. Elle représente le serveur Jabber auquel l'entité est connectée.
2- Chaque domaine utilisable de Jabber doit répondre à un "Fully Qualified Domain Name".
Le noeud ("node") est la marque secondaire. Il désigne l'utilisateur. Tous les noeuds sont contenus dans un domaine spécifique. Cependant, le noeud est facultatif (par exemple, conference.jabber.org) est une identification valide.
3- La ressource est une troisième marque facultative. Toutes les ressources appartiennent à un noeud. Dans Jabber la ressource est employée pour identifier les objets spécifiques qui appartiennent à cet utilisateur, tel que des dispositifs ou des lieux. Les ressources permettent à un seul utilisateur de maintenir plusieurs sessions simultanées avec le même serveur Jabber.
Par exemple : [email protected]/balcony et [email protected]/chamber.
Un utilisateur Jabber se connecte toujours au serveur au moyen d'une ressource particulière et a donc une adresse de la forme node@domain/resource. Cependant, puisque la ressource est facultative, l'adresse de l'utilisateur peut être de la forme node@domain (par exemple : [email protected]), ce qui est plus facile a retenir, puisqu'il est de la même forme que les adresses d'E-mail).
En général, les messages sont expédiés à une ressource spécifique, et un message destiné à [email protected] est transformé par le serveur Jabber pour que son adresse de destination correspondre a une ressource précise. Ainsi, si un message est envoyé à [email protected] (c'est a dire sans indiquer de ressource), le message est dirigé vers la ressource qui a la priorité la plus élevée, par exemple : [email protected]/balcony.
Le serveur 1.2 a ajouté un dispositif appelé le "dialback". Ce dispositif est conçu pour décourager le "spoofing", ceci rajoute une mesure de sécurité supplémentaire aux communications de serveur à serveur.
send-xml: func [ strdata ] [
insert remote strdata
]
send-connect: does [
strdata: rejoin [{<?xml version="1.0" encoding="UTF-8" ?><stream:stream to="} mainobj/m_server {" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams">}]
send-xml strdata
]
get-roster: does [
strdata: {<iq type='get'><query xmlns='jabber:iq:roster'/></iq>}
send-xml strdata
]
send-message: func [ strmessage [string!] strjid [string!] /chat ] [
either chat = true [
strdata: rejoin [{<message to="} strjid {" type="chat"><body>} convert-text/to-send strmessage {</body></message>}]
][
strdata: rejoin [{<message to="} strjid {"><body>} convert-text/to-send strmessage {</body></message>}]
]
send-xml strdata
]
strbody: xextract xhead xtail xmldata
strmessage: xextract "<body>" "</body>" strbody
if bDebug = TRUE [
alert join "Message: " strmessage ; --- contenu du message brut avant conversion utf8...
]
szRecipient: strfrom
szSend: ""
nom: ""
; Analyse message
parse strmessage [
any [
thru "["
copy nom
to "]"
( analyse-message nom )
]
]
envoi-message
send-disconnect: does [
strdata: {<presence type="unavailable"/>}
send-xml strdata
strdata: {</stream:stream>}
send-xml strdata
]
Clients :
http://webim.jabber.com
http://www.trillian.cc
http://gaim.sourceforge.net
http://exodus.sf.net
http://www.rebolfrance.org/telechargement.html
http://jplprog.freeshell.org/jabreb.htm
Liste :
http://www.jabbercentral.com/clients
Serveurs :
http://www.jabberview.com
http://yvozin.free.fr/jabber
Autres :
http://www.jabber.org
http://www.jabber-fr.com
Rebol :
http://www.rebol.com
http://www.rebolfrance.org
http://rebolzone.free.fr
http://jacdid.chez.tiscali.fr/langage/rebol.html
http://jplprog.freeshell.org/reblet.htm
Peter :
http://www.saint-andre.com/jabber
This document is copyright 2001 by Peter Saint-Andre.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation, with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. You may obtain a copy of the GNU Free Documentation License from the Free Software Foundation by visiting http:/ /www.fsf.org/ or by writing to :
The Free Software Foundation, Inc.
59 Temple Place - Suite 330
Boston, MA 02111-1307 USA
| Important |
Ce document provient du "Guide de l'Utilisateur Jabber". Vous trouverez la version originale en langue anglaise de ce document sur le site de Peter Saint-André. |
Document formatter copyright Robert M. Münch. All Rights Reserved.
XHTML 1.0 Transitional formatted with Make-Doc-Pro Version:1.0.5 on 16-Jan-2003 at 16:44:53