Journal Parlons XMPP - épisode 10 - copie de fichiers et Jingle (suite)

pour lire les épisodes précédents, suivez l'étiquette correspondante

Maintenant que nous avons vu la copie de fichiers « classique » et ses défauts, abordons une technologie qui a fait beaucoup parler d'elle — et à raison — quand elle est arrivée : Jingle.

Pour la petite histoire, Jingle est une technologie qui résulte d'un effort commun entre des membres de la XSF et une équipe chez Google qui travaillait sur un protocole de voix sur IP (VoIP). La page Wikipédia retrace succinctement l'historique. La technologie Web « WebRTC » hérite et s'inspire de ce travail.

Jingle est souvent considéré à tort comme une technologie dédiée à la visioconférence. En réalité, c'est une technologie qui permet d'établir une session Pair à Pair (P2P) et de la contrôler de manière très souple. Elle a bien été pensée à l'origine pour la visioconférence, et la XEP-0167 s'appuie dessus à cet effet, mais toute application utilisant des connexions directes (et il y en a beaucoup !) peuvent profiter de Jingle : travail collaboratif, tableau blanc, jeux, chiffrement de bout en bout (en évitant ainsi le serveur), partage d'écran, etc.
Nous allons nous intéresser plus particulièrement à une de ces applications : le transfert de fichiers.

Jingle fait une séparation claire entre l'application (ici le transfert de fichier), les transports (nous allons retrouver les connexions « in-band » et « SOCKS5 » mentionnées dans le dernier article), et la gestion de session.

Les applications et les transports sont décrits dans des extensions à part : la copie de fichiers est décrite dans la XEP-0234 « Jingle File Transfert ». Vous noterez qu'elle est toujours au statut « d'expérimental » : étant une pièce majeure du futur de XMPP, le travail est long pour obtenir quelque chose de solide et souple.

Pour les transports, nous allons donc réutiliser les XEP-0047 et XEP-0065 décrites dans le dernier article, mais en utilisant respectivement les XEP-0261 et XEP-0260 pour les adapter à Jingle. Il faut donc utiliser pas moins de 6 XEPs pour la copie de fichiers avec Jingle (2 d'entre elles servant à la réutilisation d'anciennes), et il est probable que d'autres viennent étendre les possibilités par la suite, en particulier des nouveaux transports (*). Cela peut sembler un peu compliqué, mais c'est ce qui permet la souplesse de Jingle.

Il est possible de modifier ou remplacer à tout moment un transport ou une application, et c'est là la grande force du protocole. Une vidéo passe mal à cause d'une connexion trop faiblarde ? On change l'application pour avoir une vidéo en qualité dégradée. Une connexion SOCKS5 est impossible à établir ? On remplace le transport par un transport « in-band ». Ce dernier cas appelé « plan de secours » (fallback en anglais) était un des problèmes mentionné dans le dernier article, l'ancienne méthode n'indiquant pas comment changer de transport.

Voyons maintenant le fonctionnement. Encore une fois je ne vais pas entrer trop dans les détails, vous pouvez lire la XEP si vous souhaitez les connaître.

Une session Jingle se décide et contrôle à travers le flux XML de XMPP, pour établir une connexion P2P le plus souvent externe (c.-à-d. en dehors du flux XMPP). Une session propose des contenus (« contents »). Un contenu est composé d'une application (transfert de fichier, Vidéo via RTP, etc) et d'un transport (« in-band », « SOCKS5 », « ICE-UDP », etc).
L'intérêt principal d'avoir plusieurs contenus est qu'ils sont liés dans la session : par exemple pour une visioconférence, un contenu peut s'occuper de la vidéo, et un autre de l'audio. Si un contenu dans le même logiciel mais non directement lié à la session est utilisé (par exemple un fichier est envoyé au cours de la conversation), on préférera créer une nouvelle session Jingle en parallèle plutôt qu'ajouter un contenu.

Au moment de la création de la session, nous avons 2 entités qui communiquent : l'initiateur (« initiator ») et le destinataire (« responder »). L'initiateur propose des paramètres et/ou une information pour l'application (par exemple des « codecs » pour une vidéo, ou des informations sur le fichier à transférer) ainsi que pour le transport (pour SOCKS5 les candidats par exemple).
Si le destinataire accepte la session, il négocie les paramètres en retour pour l'application (par exemple les codecs proposés qu'il connaît) ou le transport (il indique ses propres candidats dans le cas de SOCKS5).

Quand la session est acceptée, elle est considérée « active », mais il n'est pas encore possible d'échanger des données pour autant : il faut d'abord terminer la négociation et accepter un transport (dans le cas de SOCKS5 ça signifie trouver le meilleur candidat, ou changer de transport, probablement pour « in-band »).
Une fois tout en place on peut échanger les données, et éventuellement faire des changements en cours d'utilisation comme expliqué plus haut, ou donner des informations (par exemple indiquer qu'un correspondant a coupé le son (« mute »), ou qu'une sonnerie est en cours).
Selon les applications, des cas plus compliqués peuvent apparaître, comme changer le sens de transmission de données, rediriger une session (d'un appareil vers un autre par exemple), etc.

Un autre point important avec Jingle, c'est qu'il est possible de demander une pré-condition de sécurité dans une session, par exemple on peut exiger qu'une session soit chiffrée de bout en bout.

Voici une petite liste non exhaustive des améliorations apportées par Jingle rien que pour le transfert de fichiers :

• une vraie méthode de secours (« fallback »)
• les XEP-0260 et XEP-261 adaptent les XEP-0065 et XEP-0047 en tirant vraiment profit de Jingle. Ainsi la XEP-0260 permet au destinataire de fournir ses propres candidats, s'inspirant d'une extension jamais standardisée de l'ancienne méthode (appelée « fast-mode »). C'est une grosse avancée, car dans l'ancienne méthode le destinataire doit accepter (et réussir à joindre) les candidats de l'initiateur sinon la connexion échoue. L'échec peut arriver dans de nombreux cas, et si l'initiateur n'a pas de proxy, mais le destinataire en a un, celui du destinataire ne peut pas être utilisé
  Dans la méthode utilisée avec Jingle, le destinataire peut proposer son proxy, ou la connexion peut s'établir si l'initiateur est injoignable (derrière un NAT par exemple), mais pas le destinataire. L'échec est beaucoup plus rare
• il est possible de fournir la somme de contrôle (« hash ») quand on le souhaite, et ainsi la calculer au fur et à mesure. Avec l'ancienne méthode c'est tout au début ou rien, ce qui risque provoquer un ralentissement avant le transfert s'il faut faire le calcul pour un gros fichier
• avec la XEP-0234, l'initiateur peut demander un fichier au destinataire, au lieu d'uniquement pouvoir lui en proposer un.
• la XEP-0234 permet aussi l'ajout de fichiers en cours de session
• le chiffrement de bout en bout est possible et prévu, bien que non encore standardisé
• « ICE-TCP » est en cours de standardisation et devrait arriver cette année (*), permettant de mieux traverser les NATs

Au final, il est quasiment impossible d'échouer un transfert de fichier via Jingle. Le principal cas que je vois est si un des serveurs a une politique interdisant un tel transfert. Cependant, la solution de secours via le flux XMPP « in-band » est gourmande en ressources et très lente, c'est pourquoi il y a du travail sur de nouveaux transports comme ICE-TCP. Ces nouveaux transports serviront à toute application basée sur Jingle : réutiliser l'existant est un des gros points forts de Jingle, et de XMPP en général.

Jingle est une excellente technologie, avec un gros potentiel. Avec PubSub, c'est probablement un des gros piliers du XMPP de demain.

Cet article est également disponible sur mon blog. Je le mentionne ici car il vient de passer de Dotclear à Salut à Toi, autrement dit il est désormais entièrement basé sur XMPP. J'ai d'ailleurs publié une petite série d'articles sur ce dernier expliquant la mise en place d'un blog XMPP avec Libervia, son intégration dans une configuration Apache, l'import d'un blog Dotclear et enfin la publication de billets : à lire par ici.

Pour le prochain article, je ne suis pas décidé. Il est possible que je parle de chiffrement de bout en bout vu que c'est un domaine qui bouge en ce moment, ou que je continue sur la lancée Jingle avec les dépôts de fichiers. Cependant j'ai de moins en moins de temps libre, et je préfère consacrer le peu disponible au développement de SàT, le développement de la version bureau/mobiles promis en fin d'année dernière ayant commencé.

(*) cet article ayant été rédigé il y a plusieurs semaines, entre temps la XEP en question est sortie : XEP-0371