Bittorrent n'est pas vraiment complètement "hubless" - pas pour le transfert de données, mais pour la découverte de pairs. Au départ, les torrents ne pouvaient dépendre que d'un hub central appelé tracker - encore une fois, pas pour échanger des parties du fichier, mais pour découvrir qui d'autre fait partie de l'essaim. (Je crois que vous pouvez spécifier plusieurs trackers dans un protocole pour la redondance). Avec l'introduction de la DHT, un pair Bittorrent peut utiliser la DHT pour rechercher d'autres pairs, en plus ou au lieu d'utiliser un tracker. La DHT elle-même dépend de la connaissance préalable de quelques "nœuds" DHT bien connus (je ne suis pas sûr de la terminologie exacte) afin de "démarrer" un pair qui n'a pas fait de requête via la DHT depuis un certain temps.
Un client est libre d'établir une connexion avec chaque pair qu'il connaît, simultanément, et la plupart le font - à l'exception de la prise en compte de tout paramètre de "limite de connexion" pris en charge par le programme.
Desde la spécification officielle de Bittorrent :
Les connexions contiennent deux bits d'état à chaque extrémité : étouffé ou non, et intéressé ou non. L'étouffement est une notification qu'aucune donnée ne sera envoyée jusqu'à ce que l'étouffement se produise. Le raisonnement et les techniques courantes derrière l'étouffement sont expliqués plus loin dans ce document.
Le transfert de données a lieu chaque fois qu'un côté est intéressé et que l'autre côté ne s'étrangle pas. L'état d'intérêt doit être maintenu à jour à tout moment - chaque fois qu'un téléchargeur n'a pas quelque chose qu'il demanderait à un pair en mode non-étouffé, il doit exprimer son manque d'intérêt, même s'il est étouffé. L'implémentation correcte de ce principe est délicate, mais permet aux téléchargeurs de savoir quels pairs commenceront à télécharger immédiatement s'ils ne sont pas étouffés.
Les connexions commencent par être étouffées et ne sont pas intéressées.
Lorsque des données sont transférées, les téléchargeurs doivent garder plusieurs requêtes en file d'attente en même temps afin d'obtenir de bonnes performances TCP (c'est ce qu'on appelle le "pipelining"). D'autre part, les requêtes qui ne peuvent pas être écrites immédiatement dans le tampon TCP doivent être mises en file d'attente en mémoire plutôt que conservées dans un tampon réseau au niveau de l'application, afin qu'elles puissent toutes être rejetées en cas d'étranglement.
Ainsi, pour que vous obteniez des données d'un pair, ce dernier doit être "intéressé" et vous devez être "non étouffé" - selon le protocole. Plus loin :
L'étouffement est pratiqué pour plusieurs raisons. Le contrôle de congestion TCP se comporte très mal lorsqu'il envoie des messages sur plusieurs connexions à la fois. De plus, l'étouffement permet à chaque pair d'utiliser un algorithme de type "tit-for-tat" pour s'assurer qu'ils obtiennent un taux de téléchargement constant.
L'algorithme d'étouffement décrit ci-dessous est celui qui est actuellement déployé. Il est très important que tous les nouveaux algorithmes fonctionnent bien à la fois dans un réseau composé uniquement d'eux-mêmes et dans un réseau composé principalement de celui-ci. principalement de celui-ci.
Un bon algorithme d'étouffement doit répondre à plusieurs critères. Il doit plafonner le nombre de téléchargements simultanés pour de bonnes performances pour de bonnes performances. Il doit éviter l'étouffement et le désétouffement rapide, connu sous le nom de fibrillation". Il doit rendre la pareille aux pairs qui le laissent télécharger. Enfin, il doit essayer de temps en temps des connexions inutilisées pour voir si elles sont meilleures que les connexions actuelles. pour voir si elles ne sont pas meilleures que celles utilisées actuellement. unchoking optimiste.
L'algorithme d'étouffement actuellement déployé évite la fibrillation de seulement changeant qui est étouffé une fois toutes les dix secondes. Il fait de la réciprocité et le plafonnement du nombre d'envois en retirant le statut de pair aux quatre pairs pour lesquels il a les meilleurs taux de téléchargement et qui sont intéressés. Les pairs qui ont un meilleur taux de téléchargement mais qui ne sont pas intéressés ne sont pas étouffés. s'ils sont intéressés, le pire téléchargeur est étouffé. Si un téléchargeur a un fichier complet, il utilise son taux d'upload plutôt que son taux de téléchargement pour décider qui libérer.
Pour le unchoking optimiste, à tout moment, il y a un seul pair qui qui n'est pas appelé, quel que soit son taux de téléchargement (s'il est intéressé, il compte comme l'un des quatre téléchargeurs autorisés). l'un des quatre téléchargeurs autorisés). Le pair qui est optimiste optimiste change toutes les 30 secondes. Pour leur donner une chance décente de d'obtenir un morceau complet à télécharger, les nouvelles connexions sont trois fois plus trois fois plus susceptibles de commencer par le pair actuellement déséquipé de façon optimiste que n'importe où ailleurs dans la rotation. la rotation.
Ainsi, la plupart des pairs Bittorrent mettent en œuvre des algorithmes d'"étouffement" qui garantissent un fonctionnement équitable, mais accordent aux nouvelles connexions un traitement préférentiel pour leur donner une chance de faire partie intégrante de l'essaim. Un pair pourrait essayer de mettre en place un algorithme différent, plus injuste, mais sans la coopération immédiate de tous les autres pairs, le "mauvais" pair serait simplement "étouffé" jusqu'à ce qu'il ne reçoive plus de données de personne.
Plus de pairs = plus de vitesse, et les pairs plus rapides sont préférés. La capacité de chargement d'un pair, les limites de téléchargement que vous avez fixées et la capacité de chargement/téléchargement de votre lien physique influent également sur la vitesse.
J'ai (et d'autres) détaillé plus avant, à un niveau élevé, le fonctionnement de Bittorrent. à cette question .
