Comment fonctionnent les liens magnétiques BitTorrent ?

Question

Pour la première fois, j'ai utilisé un lien magnétique . Curieux de savoir comment il fonctionne, j'ai regardé les spécifications et je n'ai pas trouvé de réponse. Le wiki dit xt signifie "sujet exact" et est suivi du format ( btih dans ce cas) avec un hachage SHA1. J'ai vu la base32 mentionnée, sachant que c'est 5 bits par caractère et 32 caractères, j'ai trouvé qu'elle contient exactement 160bits, ce qui est exactement la taille du SHA1.

Il n'y a pas de place pour une adresse IP ou autre, 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 produit. Je n'ai aucune idée de la façon dont le client trouve des pairs. Comment cela fonctionne-t-il ?

Aussi, de quoi est fait le hachage ? Est-ce un hachage d'un tableau de tous les hachages de fichiers ensemble ? Peut-être que c'est un hachage du fichier torrent réel requis (en supprimant certaines informations) ?

---

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

Answer 1

Un lien magnétique BitTorrent identifie un torrent en utilisant 1 une valeur de hachage SHA-1 ou SHA-256 tronquée, appelée "infohash". Il s'agit de la même valeur que les pairs (clients) utilisent pour identifier les torrents lorsqu'ils communiquent avec les traqueurs ou d'autres pairs. Un fichier .torrent traditionnel contient une structure de données avec deux clés de niveau supérieur : announce identifier le(s) tracker(s) à utiliser pour le téléchargement, et info contenant les noms de fichiers et les hachages du torrent. L'" infohash " est le hachage du nom de fichier codé info données.

Certains liens magnétiques incluent des trackers ou des graines web, mais souvent ils ne le font pas. Votre client peut ne rien savoir du torrent, à l'exception de son infohash. La première chose qu'il doit 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 exploiter une "table de hachage distribuée" (DHT). Une DHT est un grand index distribué qui fait correspondre des torrents (identifiés par des infohashes) à des listes de pairs (identifiés par des adresses IP et des ports) qui participent à un essaim pour ce torrent (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 établit ensuite sa connexion au réseau DHT en utilisant soit des adresses codées en dur de clients contrôlés par le développeur du client, soit des clients supportant la DHT rencontrés précédemment dans un essaim de torrents. Lorsqu'il souhaite participer à un essaim pour un torrent donné, il recherche dans le réseau DHT plusieurs autres clients dont les ID sont aussi proches que possible. 3 dans la mesure du possible à l'infohash. Il informe ces clients qu'il souhaite participer à l'essaim et leur demande les informations de connexion des pairs qu'ils connaissent déjà et qui participent à l'essaim.

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

Enfin, nous pouvons demander à ces pairs pour le torrent de info des métadonnées, 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'algorithme d'analyse des données connu de l'entreprise. infohash nous sommes pratiquement dans la même position qu'un client qui a commencé avec un contrat régulier de .torrent et a obtenu une liste de pairs à partir du tracker inclus.

Le téléchargement peut commencer.

_{¹L'infohash est généralement codé en hexadécimal, mais certains anciens clients utilisaient la base 32 à la place. v1 ( <code>urn:btih:</code> ) utilise directement le condensé SHA-1, tandis que la version 2 ( <code>urn:bimh:</code> ) ajoute un <a href="https://github.com/multiformats/multihash" rel="noreferrer">multihash </a>préfixe pour identifier l'algorithme de hachage et la longueur du condensé.<br>²Il existe deux principaux réseaux DHT : le DHT "principal", plus simple, et un protocole plus compliqué utilisé par Azureus.<br>³La distance est mesurée par XOR.}

Autres lectures

• BEP-3 : La spécification du protocole BitTorrent
• BEP-52 : La spécification du protocole BitTorrent v2
• BEP-5 : Protocole DHT
• MPE-9 : Extension pour l'envoi par les pairs de fichiers de métadonnées
• MPE-10 : Protocole d'extension
• MPE-11 : Échange entre pairs (PEX)
• Description d'Azureus DHT

Answer 2

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

Je suis plus familier avec 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 "seedés" : au début, un pair se connectera à une adresse bien connue (codée en dur) pour récupérer une liste de pairs en activité. Il peut s'agir d'un amorçage direct, comme la connexion à dht.transmissionbt.com comme mentionné dans un autre article, ou l'ensemencement indirect, comme cela se fait habituellement avec JXTA, où l'homologue se connecte à une adresse qui ne fournit qu'une liste en texte brut des adresses réseau des autres homologues.

Une fois que la connexion est établie avec le(s) premier(s) pair(s), le pair qui se connecte effectue une découverte des autres pairs (en envoyant des requêtes) et maintient une table de ceux-ci. Comme le nombre d'autres pairs peut être énorme, le pair qui se connecte ne maintient qu'une partie d'une table de hachage distribuée (DHT) des pairs. L'algorithme permettant de déterminer quelle partie de la table le pair 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 le pair qui se connecte, ce dernier leur 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. L'homologue qui se connecte envoie alors une demande de découverte du lien magnétique/de la ressource aux homologues qui l'entourent. La DHT est construite de telle manière qu'elle aide à déterminer quels pairs doivent être sollicités en premier pour la ressource (pour en savoir plus, lisez Kademlia dans Wikipedia). Si le pair demandé ne détient pas la ressource demandée, il "transmet" généralement la requête à d'autres pairs récupérés dans 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 tous ses détails. Le pair qui se connecte peut alors se connecter au pair qui détient 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 dans les réseaux P2P sont pas directement attachés à des adresses réseau : ils sont distribués et c'est là toute la beauté de ces réseaux hautement évolutifs.

Answer 3

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

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

Il essaie 6 fois, en attendant 40( !) secondes entre chaque essai. Je suppose que vous pouvez le tester en supprimant les fichiers de configuration ( ~/.config/transmission sur unix), et en bloquant toute communication vers dht.transmissionbt.com et voyez ce qui se passe (attendez au moins 240 secondes).

Il semble donc que le client ait 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.

Answer 4

J'ai enfin trouvé les spécifications. Pour la première fois, Google ne m'a pas aidé. . (wiki lié à bittorrent.com qui est le site principal. J'ai cliqué sur le lien des développeurs, j'ai remarqué l'onglet bittorrent.org sur la droite, puis c'était facile à partir de là. C'est difficile de trouver des liens quand on n'a aucune idée de leur nom et qu'ils sont à plusieurs clics de distance).

Il semble que tous les torrents ont un réseau de pairs. Vous trouvez des pairs à partir des 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 liens magnétiques mais il semble qu'il n'est pas défini comment un nouveau client trouve des pairs. Peut-être que certains sont intégrés, ou qu'ils utilisent leur serveur domestique ou des trackers connus intégrés dans le client pour trouver le premier pair du réseau.

Answer 5

Lorsque j'ai commencé à répondre à votre question, je n'avais pas réalisé que vous demandiez comment fonctionne le système d'aimants. J'ai juste pensé que vous vouliez savoir comment les parties pertinentes pour le protocole bittorrent étaient générées.

---

Le hachage indiqué dans l'uri magnet est le hachage d'information du torrent encodé en base32. Le hachage d'information est le hachage sha1 du bloc d'information codé en binaire du torrent.

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

J'ai écrit une implémentation (très naïve) en C# pour tester cela puisque je n'avais pas de bencodeur sous la main et cela correspond à ce qui est attendu 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")));
}

D'après ce que j'ai compris, ce hachage n'inclut aucune information sur la façon de localiser le tracker, le client doit le découvrir par d'autres moyens (l'url d'annonce fournie). C'est juste ce qui distingue un torrent d'un autre sur le tracker.

Tout liées au protocole bittorrent tournent toujours autour du tracker. Il s'agit toujours du principal moyen de communication entre les membres de l'essaim. Le schéma magnet uri 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 sorte que vous n'avez plus besoin de télécharger des fichiers .torrent. L'uri magnet doit toujours spécifier le nom de l'utilisateur. tr acker afin de le localiser pour que le client puisse participer. Il peut contenir des informations sur d'autres protocoles mais n'est pas pertinent pour le protocole bittorrent. En définitive, le protocole bittorrent ne fonctionnera pas sans les trackers.