Un programme pour trois types de transfert

BitComet est un gestionnaire de téléchargement gratuit qui tient BitTorrent, HTTP et FTP dans la même file. La version décrite ici est 2.22. Les réunir ressemble à un petit confort et constitue en réalité la raison d'être du programme : un même fichier peut être joignable par deux de ces routes à la fois, et un gestionnaire qui n'en connaît qu'une oblige à choisir avant de savoir laquelle aurait été plus rapide.

Le cas ordinaire est plus ennuyeux et plus fréquent. Les notes de version d'un projet arrivent en HTTP, une grosse archive arrive en BitTorrent, un miroir du réseau de l'entreprise n'est joignable qu'en FTP. Une seule liste, un seul jeu de limites, un seul endroit où la progression se voit.

Le mécanisme derrière un essaim

La moitié BitTorrent suit le protocole au lieu d'en inventer un. Un transfert part d'un fichier torrent ou d'un lien magnet, et les données s'échangent avec les autres participants plutôt que d'être prises à un serveur. Chacun dans l'essaim télécharge et envoie en même temps, ce qui explique qu'un transfert populaire puisse aller plus vite qu'un serveur unique ne le pourrait jamais, et qu'un transfert peu demandé soit proche de l'arrêt.

C'est une description du mécanisme, pas une prise de position sur ce qu'il faudrait transférer. Le protocole est indifférent au contenu, le client aussi ; la vitesse d'un essaim dépend du nombre de personnes qui le détiennent à ce moment.

Le problème des quatre-vingt-dix-neuf pour cent

Le point faible de la conception est la fin d'un transfert. Si les seuls participants qui détiennent les pièces manquantes s'en vont, le téléchargement reste à quatre-vingt-dix-neuf pour cent — le fichier est inutilisable, la place reste occupée, et rien dans l'interface n'explique pourquoi.

Les seeds de longue durée s'occupent précisément de cela. Les pièces déjà vues restent disponibles plus longtemps que les pairs qui les détenaient par hasard, si bien qu'un transfert qui calerait ailleurs peut se terminer quelque part. Le même mécanisme se voit souvent plus tôt sous forme de vitesse : un transfert adossé à une source de longue durée n'a pas à attendre que suffisamment de pairs se présentent à une heure commode.

Écrire à travers un cache

Le cache disque est la fonction la moins visible et celle dont les conséquences durent le plus. Un téléchargement, ce sont des milliers de petites écritures dispersées dans un fichier encore en cours d'assemblage ; fait directement, ce schéma tient un disque occupé à chercher et le fatigue. Rassembler les pièces en mémoire et les écrire par lots plus grands et ordonnés réduit le nombre d'opérations de lecture et d'écriture : c'est exactement ce que le programme revendique, moins d'usure plutôt que plus de vitesse.

Cela explique aussi un comportement que les utilisateurs remarquent : les dernières secondes avant qu'une tâche soit annoncée terminée servent parfois à écrire plutôt qu'à recevoir.

Lire une vidéo qui arrive encore

La fonction souvent appelée lecture pendant le téléchargement tient à une décision : récupérer d'abord le début et la fin d'un fichier média. Le début est ce dont un lecteur a besoin pour démarrer, et la fin contient l'index que beaucoup de conteneurs y placent ; avec les deux, la lecture peut commencer pendant que le milieu se transfère. Sans la fin, un lecteur qui exige l'index refusera de démarrer, peu importe la quantité déjà arrivée.

Sa place

BitComet n'est pas un projet open source et ne prétend pas l'être ; il est gratuit et conçu pour ceux qui laissent tourner une file, non pour ceux qui récupèrent un fichier par mois. Le résumé honnête : les trois protocoles, les seeds de longue durée et la lecture pendant le téléchargement décident s'il convient — si le travail mêle plusieurs routes et quelques gros transferts qui ne doivent pas mourir à quatre-vingt-dix-neuf pour cent, c'est pour cela que le programme existe.