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 consulté les spécifications et je n'ai trouvé aucune réponse. Le wiki dit xtsignifie "sujet exact" et est suivi du format ( btihdans ce cas) 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 contenait exactement 160 bits, ce qui correspond 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 ou autre, mais rien ne s'est passé. Je n'ai aucune idée de la façon dont le client trouve ses pairs. Comment cela marche-t-il?

Aussi, de quoi est le hash? Est-ce un hachage d'un tableau de tous les hachages de fichiers ensemble? Peut-être s'agit-il d'un hachage du fichier torrent requis (suppression de certaines informations)?

Dans une VM, j'ai essayé un lien magnétique avec uTorrent (qui venait d'être 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 ¹ une valeur de hachage SHA-1 ou SHA-256 tronquée connue sous le nom de "infohash". Il s'agit de la même valeur que les pairs (clients) utilisent pour identifier les torrents lorsqu'ils communiquent avec des trackers ou d'autres pairs. Un fichier .torrent traditionnel contient une structure de données avec deux clés de niveau supérieur:, announceidentifiant le (s) tracker (s) à 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 infodonnées encodées .

Certains liens magnétiques incluent des trackers ou des graines Web, mais ce n'est souvent pas le cas. Votre client ne sait peut-être rien du torrent, à l'exception de son infohash. La première chose dont il a besoin est de trouver d'autres pairs qui téléchargent le torrent. Il le fait en utilisant un réseau peer-to-peer séparé ² exploitant une "table de hachage distribuée" (DHT). Un DHT est un gros index distribué qui mappe des torrents (identifiés par des infohashes) à des listes de pairs (identifiés par leur adresse IP et leurs ports) qui participent à un essaim pour ce torrent (téléchargement / téléchargement de données ou de métadonnées).

La première fois qu'un client rejoint le réseau DHT, il génère un ID aléatoire de 160 bits à partir du même espace que les infohashes. Il initialise ensuite sa connexion au réseau DHT en utilisant soit des adresses codées en dur des clients contrôlés par le développeur client, soit des clients prenant en charge DHT précédemment rencontrés dans un essaim de torrent. Quand il veut participer à un essaim pour un torrent donné, il recherche le réseau DHT pour plusieurs autres clients dont les ID sont aussi proches ³ possible du infohash. Il notifie à 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 des 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 DHT à des demandes constantes. Une fois que vous avez appris l'existence de quelques pairs de la DHT, votre client pourra demander à ces pairs les informations de connexion d'encore plus de 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 infométadonnées 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 en utilisant le connu infohash, nous sommes pratiquement dans la même position qu'un client qui a commencé avec un .torrentfichier normal et a obtenu une liste de pairs du tracker inclus.

Le téléchargement peut commencer.

_{¹ L'infohash est typiquement codé en hexadécimal, mais certains anciens clients utilisaient à la place la base 32. v1 ( urn:btih:) utilise directement le condensé SHA-1, tandis que v2 ( urn:bimh:) ajoute un préfixe multihash pour identifier l'algorithme de hachage et la longueur du condensé.
² Il existe deux réseaux DHT principaux: le DHT «principal» plus simple et un protocole plus complexe utilisé par Azureus.
³ La distance est mesurée par XOR.}

Lectures complémentaires

• BEP-3: la spécification du protocole BitTorrent
• BEP-52: La spécification du protocole BitTorrent v2
• BEP-5: protocole DHT
• BEP-9: Extension permettant aux pairs d'envoyer des fichiers de métadonnées
• BEP-10: Protocole d'extension
• BEP-11: échange entre pairs (PEX)
• Description de l'Azureus DHT

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

Je connais mieux JXTA mais tous les réseaux peer to peer fonctionnent 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 pair se connectera à une adresse bien connue (codée en dur) pour récupérer une liste de pairs en cours d'exécution. Il peut s'agir d'un amorçage direct comme la connexion à dht.transmissionbt.comcomme mentionné dans un autre article ou d'un amorçage indirect comme généralement fait avec JXTA où le pair se connecte à une adresse qui ne fournit qu'une liste en texte brut des autres adresses réseau des pairs.

Une fois la connexion établie avec le (s) premier (s) pair (s), l'homologue qui se connecte effectue une découverte des autres pairs (en envoyant des requêtes) et en maintient un tableau. Étant donné que le nombre d'autres pairs peut être énorme, l'homologue qui se connecte ne gère qu'une partie d'une table de hachage distribuée (DHT) des pairs. L'algorithme pour déterminer la partie de la table que l'homologue qui se connecte doit maintenir varie en fonction du réseau. BitTorrent utilise Kademlia avec des identifiants / clés de 160 bits.

Découverte des ressources

Une fois que quelques pairs ont été découverts par l'homologue qui se connecte, ce dernier leur envoie quelques requêtes de découverte de ressources. Les liens magnétiques identifient ces ressources et sont construits de telle manière qu'ils sont une «signature» pour une ressource et garantissent qu'ils identifient de manière unique le contenu demandé parmi tous les pairs. L'homologue qui se connecte enverra alors une demande de découverte pour le lien / la ressource magnétique aux pairs qui l'entourent. Le DHT est construit de telle manière qu'il aide à déterminer quels pairs doivent être sollicités en premier pour la ressource (lisez sur Kademlia dans Wikipedia pour plus). Si l'homologue demandé ne détient pas la ressource demandée, il "transmettra" généralement la requête à d'autres homologues extraits de son 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 tous ses détails. Le pair qui se connecte peut alors se connecter au pair détenant la ressource (directement ou via un relais - je n'entrerai pas dans les détails ici) et commencer à la récupérer.

Les ressources / services des réseaux P2P ne sont pas directement rattachés aux adresses réseau: ils sont distribués et c'est la beauté de ces réseaux hautement évolutifs.

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

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

Il essaie cela 6 fois, en attendant 40 (!) Secondes entre les essais. Je suppose que vous pouvez le tester en supprimant les fichiers de configuration ( ~/.config/transmissionsous 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 d'amorçage intégré pour commencer. Bien sûr, une fois qu'il est entré dans le réseau, il n'a plus besoin de ce nœud d'amorçage.

J'ai finalement trouvé des spécifications. 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 des développeurs, remarquez l'onglet bittorrent.org sur la droite puis c'était facile à partir de là. Ses liens difficiles à trouver quand vous n'avez aucune idée de ce qu'ils sont étiquetés et beaucoup clics).

Il semble que tous les torrents aient un réseau de pairs. Vous trouvez des pairs parmi les trackers et vous les gardez 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 des liens magnétiques, mais il semble que la façon dont un nouveau client trouve des pairs n'est pas définie. Certains d'entre eux sont peut-être intégrés ou utilisent leur serveur domestique ou des trackers connus intégrés au client pour obtenir le premier pair du réseau.

Quand j'ai commencé à répondre à votre question, je ne savais pas que vous demandiez comment fonctionne le système magnétique. Je pensais juste que vous vouliez savoir comment les parties pertinentes pour le protocole bittorrent ont été générées.

Le hachage répertorié dans l'URI de l'aimant est le hachage d'informations du torrent encodé en base32. Le hachage d'informations est le hachage 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 cela car je n'avais pas de bencoder sous la main et cela correspond à ce que l'on attend du client.

static string CalculateInfoHash(string 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 String.Join("", bytes.Select(b => b.ToString("X2")));
}

Si je comprends bien, ce hachage n'inclut aucune information sur la façon de localiser le traqueur, le client doit le découvrir par d'autres moyens (l'url d'annonce fournie). C'est précisément 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 l'essaim. Le schéma d'URI d'aimant n'a pas été conçu spécifiquement pour être utilisé par bittorrent. Il est utilisé par tous les protocoles P2P comme une 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'URI d'aimant doit encore spécifier l' tracker afin de le localiser afin que le client puisse 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 remplie à partir du torrent qui met à jour le client (par exemple, il y a un torrent pour utorrent qui le met à jour). 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.