Comment fonctionnent les liens magnétiques BitTorrent?

Pour la première fois, j’ai utilisé un lien magnétique . Curieux de savoir comment cela fonctionne, j’ai cherché les spécifications et je n’ai trouvé aucune réponse. Le wiki indique que xt signifie “sujet exact” et est suivi par le format (dans ce cas-ci) avec un hachage SHA1. J’ai vu base32 mentionné, sachant que c’est 5 bits par caractère et 32 ​​caractères, j’ai trouvé qu’il contient exactement 160 bits, ce qui est exactement la taille du SHA1.

Il n’y a pas de place pour une adresse IP ou quoi que ce soit, c’est juste un SHA1. Alors, comment le client BitTorrent trouve-t-il le fichier réel? J’ai activé URL Snooper pour voir s’il visite une page (en utilisant TCP) ou effectue une recherche, etc., mais rien ne s’est passé. Je n’ai aucune idée de la façon dont le client trouve des pairs. Comment cela marche-t-il?

En outre, quel est le hash de? Est-ce un hachage d’un tableau de tous les hachages de fichiers ensemble? Peut-être est-ce un hachage du fichier torrent réel requirejs (dépouillant certaines informations)?


Dans une VM, j’ai essayé un lien magnétique avec uTorrent (qui a été récemment installé) et il a réussi à trouver des pairs. D’où vient le premier pair? C’était frais et il n’y avait pas d’autres torrents.

Un lien magnétique BitTorrent identifie un torrent en utilisant 1 une valeur de hachage SHA-1 ou SHA-256 tronquée connue sous le nom de “infohash”. C’est la même valeur que les pairs (clients) utilisent pour identifier les torrents lors de la communication avec les suiveurs ou d’autres homologues. Un fichier .torrent traditionnel contient une structure de données avec deux clés de niveau supérieur: announce , identifiant le ou les trackers à utiliser pour le téléchargement et info , contenant les noms de fichiers et les hachages pour le torrent. Le “infohash” est le hachage des données d’ info codées.

Certains liens magnétiques incluent des trackers ou des graines Web, mais ils ne le font pas souvent. Votre client peut ne rien savoir sur le torrent, à l’exception de son infohash. La première chose à faire est de trouver d’autres pairs qui téléchargent le torrent. Pour ce faire, il utilise un réseau peer-to-peer distinct 2 exploitant une “table de hachage dissortingbuée” (DHT). Un DHT est un gros index dissortingbué qui fait correspondre les torrents (identifiés par infohashes) à des listes de pairs (identifiées par adresse IP et ports) qui participent à un essaim pour ce torrent (chargement / téléchargement de données ou métadonnées).

La première fois qu’un client rejoint le réseau DHT, il génère un identifiant aléatoire de 160 bits à partir du même espace que infohashes. Il amorce ensuite sa connexion au réseau DHT en utilisant soit les adresses codées en dur des clients contrôlés par le développeur du client, soit les clients prenant en charge DHT précédemment rencontrés dans un essaim de torrent. Lorsqu’il souhaite participer à un essaim pour un torrent donné, il recherche sur le réseau DHT plusieurs autres clients dont les identifiants sont aussi proches 3 que possible de l’infohash. Il avertit ces clients qu’il souhaite participer à l’essaim et leur demande les informations de connexion de tous les pairs qu’ils connaissent déjà et qui participent à l’essaim.

Lorsque les pairs téléchargent / téléchargent un torrent particulier, ils essaient de se parler de tous les autres pairs qu’ils connaissent et qui participent au même essaim de torrent. Cela permet aux pairs de se connaître rapidement, sans soumettre un tracker ou une DHT à des requêtes constantes. Une fois que vous aurez appris l’existence de quelques pairs de la DHT, votre client pourra demander à ses pairs les informations de connexion d’autres pairs dans l’essaim de torrent, jusqu’à ce que vous ayez tous les pairs dont vous avez besoin.

Enfin, nous pouvons demander à ces pairs les métadonnées d’ info du torrent, contenant les noms de fichiers et la liste de hachage. Une fois que nous avons téléchargé ces informations et vérifié qu’elles sont correctes à l’aide de l’ infohash connu, nous sums pratiquement dans la même position qu’un client qui a démarré avec un fichier .torrent classique et a obtenu une liste de clients du tracker inclus.

Le téléchargement peut commencer.

1 L’infohash est généralement codé en hexadécimal, mais certains anciens clients utilisaient plutôt la base 32. v1 ( urn:btih: utilise directement le résumé SHA-1, tandis que v2 ( urn:bimh: ajoute un préfixe multi – shash pour identifier l’algorithme de hachage et la longueur de résumé.
2 Il existe deux réseaux DHT principaux: le DHT “plus simple” et un protocole plus complexe utilisé par Azureus.
3 La distance est mesurée par XOR.

Lectures complémentaires

  • BEP-3: Spécification du protocole BitTorrent
  • BEP-52: Spécification du protocole BitTorrent v2
  • BEP-5: Protocole DHT
  • BEP-9: Extension pour les pairs d’envoyer des fichiers de métadonnées
  • BEP-10: Protocole d’extension
  • BEP-11: Echange de pairs (PEX)
  • Azureus DHT Description

La découverte par les pairs et la découverte des ressources (fichiers dans votre cas) sont deux choses différentes.

Je suis plus familier avec JXTA mais tous les réseaux de pair à pair travaillent sur les mêmes principes de base.

La première chose à faire est la découverte par les pairs.

Découverte par les pairs

La plupart des réseaux P2P sont des réseaux “amorcés”: lors du premier démarrage, un homologue se connectera à une adresse connue (codée en dur) pour récupérer une liste des homologues en cours d’exécution. Cela peut être un amorçage direct, comme la connexion à dht.transmissionbt.com comme mentionné dans un autre article ou un dht.transmissionbt.com indirect, comme c’est généralement le cas avec JXTA où l’homologue se connecte à une adresse

Une fois la connexion établie avec le premier (petit) homologue, l’homologue de connexion effectue une découverte d’autres homologues (en envoyant des demandes) et en conserve une table. Étant donné que le nombre d’autres pairs peut être énorme, le pair qui se connecte ne conserve qu’une partie de la table de hachage dissortingbuée (DHT) des homologues. L’algorithme permettant de déterminer la partie de la table que l’homologue connecté doit gérer varie selon le réseau. BitTorrent utilise Kademlia avec des identificateurs / clés de 160 bits.

Découverte de ressources

Une fois que quelques pairs ont été découverts par l’homologue connecté, ce dernier envoie quelques demandes de découverte de ressources. Les liens magnétiques identifient ces ressources et sont construits de telle manière qu’ils constituent une “signature” pour une ressource et garantissent qu’ils identifient de manière unique le contenu demandé parmi tous les pairs. Le pair qui se connecte enverra alors une demande de découverte pour le lien / la ressource d’aimant à ses pairs. Le DHT est conçu de telle manière qu’il aide à déterminer quels pairs doivent être interrogés en premier pour la ressource (lisez Kademlia sur Wikipedia pour plus d’informations). Si l’homologue demandé ne contient pas la ressource demandée, il transmettra généralement la requête à d’autres homologues récupérés à partir de sa propre DHT.

Le nombre de “sauts” sur lesquels la requête peut être transmise est généralement limité; 4 est un nombre habituel avec les réseaux de type JXTA.

Lorsqu’un pair détient la ressource, il répond avec ses détails complets. Le pair qui se connecte peut alors se connecter à l’homologue détenant la ressource (directement ou via un relais – je n’entrerai pas dans les détails ici) et commencer à le récupérer.

Les ressources / services dans les réseaux P2P ne sont pas directement liés aux adresses réseau: ils sont dissortingbués et c’est la beauté de ces réseaux hautement évolutifs.

J’étais curieux de la même question moi-même. En lisant le code pour la transmission, j’ai trouvé ce qui suit dans libtrnasmission/tr-dht.c :

 3248: bootstrap_from_name( "dht.transmissionbt.com", 6881, bootstrap_af(session) ); 

Il essaye ça 6 fois, attendant 40 secondes! Je suppose que vous pouvez le tester en supprimant les fichiers de configuration ( ~/.config/transmission sur unix) et en bloquant toutes les communications vers dht.transmissionbt.com , et voir ce qui se passe (attendez au moins 240 secondes).

Il semble donc que le client dispose d’un nœud bootstrap intégré pour commencer. Bien sûr, une fois dans le réseau, il n’a plus besoin de ce nœud bootstrap.

J’ai finalement trouvé la spécification. Pour la première fois, Google n’a pas aidé . (wiki lié à bittorrent.com qui est le site principal. J’ai cliqué sur le lien pour les développeurs, notez l’onglet bittorrent.org à droite puis c’était facile à partir de là. Ses liens difficiles à trouver quand vous n’avez aucune idée clique).

Il semble que tous les torrents aient un réseau de pairs. Vous trouvez des pairs de trackers et vous les conservez entre les sessions. Le réseau vous permet de trouver des pairs et d’autres choses. Je n’ai pas lu comment il est utilisé avec les liens magnétiques, mais il semble que ce ne soit pas défini comment un nouveau client trouve des pairs. Peut-être certains sont-ils intégrés ou utilisent-ils leur serveur domestique ou des trackers connus intégrés au client pour obtenir le premier homologue du réseau.

Quand j’ai commencé à répondre à votre question, je n’avais pas réalisé que vous demandiez comment fonctionne le schéma d’aimants. Juste pensé que vous vouliez savoir comment les parties pertinentes pour le protocole bittorrent ont été générées.


Le hash indiqué dans l’aimant est le hash info du torrent encodé en base32. Le hash info est le hash sha1 du bloc d’informations bencodé du torrent.

Ce code python montre comment il peut être calculé.

J’ai écrit une implémentation C # (très naïve) pour tester ceci car je n’avais pas de bencoder sous la main et cela correspond à ce que l’on attend du client.

 static ssortingng CalculateInfoHash(ssortingng path) { // assumes info block is last entry in dictionary var infokey = "e4:info"; var offset = File.ReadAllText(path).IndexOf(infokey) + infokey.Length; byte[] fileHash = File.ReadAllBytes(path).Skip(offset).ToArray(); byte[] bytes; using (SHA1 sha1 = SHA1.Create()) bytes = sha1.ComputeHash(fileHash, 0, fileHash.Length - 1); // need to remove last 'e' to compensate for bencoding return Ssortingng.Join("", bytes.Select(b => b.ToSsortingng("X2"))); } 

Si je comprends bien, ce hachage n’inclut aucune information sur la façon de localiser le dispositif de suivi, le client doit le découvrir par d’autres moyens (l’URL d’annonce fournie). C’est ce qui distingue un torrent d’un autre sur le tracker.

Tout ce qui concerne le protocole bittorrent tourne toujours autour du tracker. C’est toujours le principal moyen de communication entre les essaims. Le schéma d’aimant magnétique n’a pas été conçu spécifiquement pour être utilisé par bittorrent. Il est utilisé par tous les protocoles P2P comme forme alternative de communication. Les clients Bittorrent se sont adaptés pour accepter les liens magnétiques comme un autre moyen d’identifier les torrents. De cette façon, vous n’avez plus besoin de télécharger des fichiers .torrent. L’aimant uri a encore besoin de spécifier l’acquéreur pour le localiser afin que le client puisse y participer. Il peut contenir des informations sur d’autres protocoles mais n’est pas pertinent pour le protocole bittorrent. Le protocole bittorrent ne fonctionnera finalement pas sans les trackers.

la liste des pairs est probablement alimentée par le torrent qui met à niveau le client (par exemple, il existe un torrent pour utorrent qui le met à niveau). Tant que tout le monde utilise le même client, cela devrait être bon car vous n’avez pas d’autre choix que de partager la mise à niveau.