Comment fonctionnent les liens magnétiques BitTorrent?


157

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.


3
Est-ce même pertinent pour la programmation?
Krypton

Réponses:


156

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". 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é 2 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 3 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.

1 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é.
2 Il existe deux réseaux DHT principaux: le DHT «principal» plus simple et un protocole plus complexe utilisé par Azureus.
3 La distance est mesurée par XOR.

Lectures complémentaires


1
Le nœud de bootstrap, par exemple, est dht.transmission.com-il simplement un tracker? La façon dont je comprends les choses est qu'il doit garder une trace de la liste des pairs par hachage d'informations - ce qui est exactement ce que fait un tracker.
Kar

3
@Kate Pas exactement. Un nœud DHT typique stocke des listes de pairs pour certains torrents qui sont «proches» de lui dans «l'espace» du réseau DHT. Un tracker essaie plutôt de stocker des listes de pairs pour chaque torrent qu'il connaît. De plus, les nœuds DHT bootstrap ne stockent pas spécifiquement les listes de pairs pour les torrents. Au lieu de cela, ils ne distribuent que des listes d'autres nœuds DHT, pour vous aider à vous connecter à l'ensemble du réseau. Vous pouvez ensuite trouver un nœud DHT typique avec la liste de pairs qui vous intéresse.
Jeremy Banks

"Certains liens magnétiques incluent des trackers ou des graines Web" - Je suis un peu confus. Magnet est utilisé pour télécharger le fichier torrent comme vous le décrivez. De la spécification d'URI de Magnet, je vois "source acceptable" et "traqueur" comme des informations qui peuvent être encodées dans l'URI. Maintenant, le tracker est évidemment spécifique à Bittorrent et sera très probablement utilisé en plus des trackers répertoriés dans le fichier torrent. La "source acceptable" est-elle destinée à être utilisée pour télécharger le fichier torrent ou (l'un des) fichiers réels à télécharger via le fichier Torrent?
Frederick Nord

@FrederickNord Lors de la prise en charge des clients torrent, le ws=paramètre pointe vers une URL d'amorce Web BEP-19 des données réelles, et le xs=paramètre pointe vers une URL contenant le .torrentfichier lui-même. Je pense que c'est un peu incompatible avec d'autres utilisations du magnet:système, mais c'est comme ça. J'oublie si des clients l'utilisent as=pour quelque chose ... peut-être juste comme solution de secours xs=, mais pas largement supportée, IIRC.
Jeremy Banks

46

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.


Je pense que c'est la réponse la plus succincte sans beaucoup de jargon technique. Merci.
desaivv

26

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.


9

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.


Ah, je suppose que j'avais raison d'aller à DHT pour trouver des clients. "Si aucun tracker n'est spécifié, le client DEVRAIT utiliser le DHT (BEP 0005 [3]) pour acquérir des pairs."
Jeff Mercado

8

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.


2
Cela n'aide pas. Mais dites-vous qu'il hache tout le fichier torrent en ignorant le bloc infokey? Ma question portait sur la façon dont il trouve les pairs.

1
@ acidzombie24 Vous pensez probablement aux trackers distribués qui utilisent DHT pour localiser les pairs. Cela n'a rien à voir avec les liens magnétiques. ( en.wikipedia.org/wiki/… )
Alexander Sagen

2
@Jeff M: Mais qu'est-ce qui «renvoie» une liste de pairs. Un lien est juste un lien, aucun tracker ne lui est associé. J'essayais de comprendre CE QUI renvoie les pairs.

1
+1. De plus, le lien magnétique en question ne spécifie pas tr (acker). Seulement th sha1 qui m'a laissé confus. Surtout lorsque j'utilise une nouvelle installation sans torrents en cours d'exécution (et que je ne suis connecté à aucun pair) et que le lien magnétique trouve des pairs. C'est magique, je n'ai aucune idée de comment ça marche. Il doit y avoir un serveur domestique qu'il peut demander à des pairs. Mais cela signifie-t-il que j'envoie des requêtes à des pairs à la recherche d'un hachage et que le client transmet le message à de nombreux pairs jusqu'à ce que l'un d'eux réponde à mon appel?

1
Je ne sais pas trop comment y répondre. Tous les uris magnétiques que j'ai vus spécifient toujours le traqueur. Il se peut que votre client essaie une liste de trackers publics dont il connaît l'existence et que l'un d'entre eux en possède. Quels trackers le torrent associé répertorie-t-il comme étant utilisé? Comment est-il affiché? Y a-t-il une relation entre le tracker auquel il se connecte et la source du lien magnétique? C'est peut-être un torrent qui utilise DHT? Est-ce que la même chose fonctionne pour un torrent privé? Encore une fois, je ne sais pas comment fonctionne la DHT exactement. Je vais voir si je peux trouver plus d'informations.
Jeff Mercado

3

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.


C'est un endroit très logique pour rechercher le hachage et d'autres pairs. +1
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.