On mélange allégrement deux choses ici. XMPP (le protocole) est prévu pour échange du XML entre plusieurs clients passant par un serveur, le tout fédéré (i.e. truc@bidule.com peut échanger avec machin@chose.net). Jabber, l'application de ce protocole à la messagerie instantanée, permet donc d'échanger des messages (du texte) entre plusieurs utilisateurs de plusieurs serveurs, mais toujours en passant par ces serveurs. Dans les deux cas, on a un protocole TCP bien défini, qui s'appuie sur des numéros de ports enregistrés à l'IANA, etc.
Des règles de sortie restrictives
Sauf que ces numéros de ports (5999 et compagnie) sont parfois bloqués en sortie dans les entreprises (et autres réseaux un peu coincés du QoS). C'est le premier problème de NAT qu'on peut imputer à Jabber, et qui est globalement réglé par les clients Web. Ces derniers existent depuis la fin des années 90, et fonctionnaient alors essentiellement côté serveur : un formulaire, qui envoie à du code serveur (PHP & co) les requêtes, qui les envoie à son tour au serveur XMPP (auprès duquel il s'est auparavant authentifié), et retour.
Tout cela était bien joli, mais avec la mode de l'AJAX, c'est devenu particulièrement pas sexy comme manière de faire. On a donc commencé à réfléchir à la meilleure manière d'établir la connexion au serveur XMPP directement depuis le code Javascript du client. Ce dernier étant habitué à manipuler du DOM (éventuellement XML), manipuler des messages XMPP n'aurait pas du lui faire trop peur. Sauf que Javascript dans un navigateur, ça ne sait pas trop se connecter à un protocole TCP quelconque. On a donc produit un certain nombre de contournements techniques, les deux plus récents (et intéressants) étant :
BoSH (Binary over Streamed HTTP, de mémoire), qui encapsule le plus proprement possible le dialogue XMPP dans du HTTP.
XMPP-over-Websockets, qui est clairement l'avenir mais mal défini/supporté pour l'instant.
Concrètement un point d'entrée BoSH est une URL HTTP(S) standard, qui fait l'interface entre un serveur XMPP (la plupart permettent de servir directement cette URL, sinon il y a des proxies autonomes faciles à déployer) et le client Web. Évidemment, les problématiques de "cross origin" s'appliquent, on a donc intérêt à servir directement un point d'entrée BoSH sur le domaine qu'on héberge, si on le peut.
Les clients "lourds" ont sauté en marche de le "BoSH train", et certains peuvent effectivement se connecter via une URL BoSH, ce qui permet - mais l'intention initiale n'était pas là - de contourner les règles de sortie les plus restrictives.
Des connexions directes
Depuis qu'il est question de voix et de vidéo dans les outils de messagerie instantanée (et donc bien avant Skype), il est clair pour à peu près tout le monde que le modèle client->serveur->client n'est pas satisfaisant, pour des raisons de bande passante. On a donc depuis très longtemps (MSN le faisait déjà, de mémoire) fait en sorte que les clients soient capables de négocier (avec l'aide du serveur) un canal de communication direct. Chez XMPP, comme on n'aime pas faire les choses de manière inélégante, on a mis très (trop?) longtemps à produire une spec correcte, et c'est finalement Google qui a sorti tout le monde de l'ornière. Ils ont en effet défini une manière de faire (Jingle) pour GTalk, et ont soumis leur spec à l'organisme de standardisation d'XMPP. Je passe sur les allers-retours de la norme, sur le fait que GTalk a longtemps utilisé une version de Jingle qui n'était plus celle recommandée par XMPP… bref.
Dans les grandes lignes, Jingle permet à deux clients de :
déterminer leur capacité à communiquer malgré leurs éventuels NATs respectifs
utiliser un intermédiaire (i.e. proxy) en cas d'incapacité
choisir des codecs audio et vidéo communs
L'ennui majeur ici, c'est que le cas où l'on doit passer par un proxy est beaucoup trop fréquent, et que placer cette charge sur une seule machine n'est pas raisonnable. Une solution supplémentaire a été trouvée (et est implémentée au moins par Jitsi et OneTeam) : Jingle Nodes. Dans Nodes, on pousse la logique un peu plus loin, et on permet à un client qui a les bonnes caractéristiques (en termes de NAT) de se comporter en proxy. On répartit ainsi la charge sur un maximum de machines/connexions.
Bon, aux dernières nouvelles, la spec est un peu morte.
[^] # Re: La guerre des écosystèmes continue
Posté par Larry Cow . En réponse au journal Google Hangouts remplace Talk: la fin de la fédération XMPP ?. Évalué à 10.
On mélange allégrement deux choses ici. XMPP (le protocole) est prévu pour échange du XML entre plusieurs clients passant par un serveur, le tout fédéré (i.e. truc@bidule.com peut échanger avec machin@chose.net). Jabber, l'application de ce protocole à la messagerie instantanée, permet donc d'échanger des messages (du texte) entre plusieurs utilisateurs de plusieurs serveurs, mais toujours en passant par ces serveurs. Dans les deux cas, on a un protocole TCP bien défini, qui s'appuie sur des numéros de ports enregistrés à l'IANA, etc.
Des règles de sortie restrictives
Sauf que ces numéros de ports (5999 et compagnie) sont parfois bloqués en sortie dans les entreprises (et autres réseaux un peu coincés du QoS). C'est le premier problème de NAT qu'on peut imputer à Jabber, et qui est globalement réglé par les clients Web. Ces derniers existent depuis la fin des années 90, et fonctionnaient alors essentiellement côté serveur : un formulaire, qui envoie à du code serveur (PHP & co) les requêtes, qui les envoie à son tour au serveur XMPP (auprès duquel il s'est auparavant authentifié), et retour.
Tout cela était bien joli, mais avec la mode de l'AJAX, c'est devenu particulièrement pas sexy comme manière de faire. On a donc commencé à réfléchir à la meilleure manière d'établir la connexion au serveur XMPP directement depuis le code Javascript du client. Ce dernier étant habitué à manipuler du DOM (éventuellement XML), manipuler des messages XMPP n'aurait pas du lui faire trop peur. Sauf que Javascript dans un navigateur, ça ne sait pas trop se connecter à un protocole TCP quelconque. On a donc produit un certain nombre de contournements techniques, les deux plus récents (et intéressants) étant :
Concrètement un point d'entrée BoSH est une URL HTTP(S) standard, qui fait l'interface entre un serveur XMPP (la plupart permettent de servir directement cette URL, sinon il y a des proxies autonomes faciles à déployer) et le client Web. Évidemment, les problématiques de "cross origin" s'appliquent, on a donc intérêt à servir directement un point d'entrée BoSH sur le domaine qu'on héberge, si on le peut.
Les clients "lourds" ont sauté en marche de le "BoSH train", et certains peuvent effectivement se connecter via une URL BoSH, ce qui permet - mais l'intention initiale n'était pas là - de contourner les règles de sortie les plus restrictives.
Des connexions directes
Depuis qu'il est question de voix et de vidéo dans les outils de messagerie instantanée (et donc bien avant Skype), il est clair pour à peu près tout le monde que le modèle client->serveur->client n'est pas satisfaisant, pour des raisons de bande passante. On a donc depuis très longtemps (MSN le faisait déjà, de mémoire) fait en sorte que les clients soient capables de négocier (avec l'aide du serveur) un canal de communication direct. Chez XMPP, comme on n'aime pas faire les choses de manière inélégante, on a mis très (trop?) longtemps à produire une spec correcte, et c'est finalement Google qui a sorti tout le monde de l'ornière. Ils ont en effet défini une manière de faire (Jingle) pour GTalk, et ont soumis leur spec à l'organisme de standardisation d'XMPP. Je passe sur les allers-retours de la norme, sur le fait que GTalk a longtemps utilisé une version de Jingle qui n'était plus celle recommandée par XMPP… bref.
Dans les grandes lignes, Jingle permet à deux clients de :
L'ennui majeur ici, c'est que le cas où l'on doit passer par un proxy est beaucoup trop fréquent, et que placer cette charge sur une seule machine n'est pas raisonnable. Une solution supplémentaire a été trouvée (et est implémentée au moins par Jitsi et OneTeam) : Jingle Nodes. Dans Nodes, on pousse la logique un peu plus loin, et on permet à un client qui a les bonnes caractéristiques (en termes de NAT) de se comporter en proxy. On répartit ainsi la charge sur un maximum de machines/connexions.
Bon, aux dernières nouvelles, la spec est un peu morte.