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 xt signifie "sujet exact" et est suivi du format (btih dans ce cas) avec un hachage SHA1. J'ai vu Base32 mentionné, sachant qu'il s'agit de 5 bits par caractère et de 32 caractères. J'ai constaté 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. Comment le client BitTorrent trouve-t-il le fichier réel? J'ai activé URL Snooper pour savoir s'il visitait une page (à l'aide de TCP) ou effectuait une recherche, etc., mais rien ne s'est passé. Je ne sais pas du tout comment le client trouve ses pairs. Comment cela marche-t-il?
Aussi, quel est le hash de? Est-ce que c'est 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 (effaçant certaines informations)?
Dans une machine virtuelle, j'ai essayé une liaison magnétique avec uTorrent (qui venait d'être installée) et elle 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 utilisant1 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 lors de la communication avec des suivis ou d'autres pairs. Un fichier .torrent traditionnel contient une structure de données avec deux clés de niveau supérieur: announce, identifiant le (s) suivi (s) à utiliser pour le téléchargement, et info, contenant les noms de fichier et les hachages pour le fichier. torrent. "Infohash" est le hachage des données info codées.
Certains liens aimantés incluent des trackers ou des graines Web, mais souvent pas. Votre client peut ne rien savoir du 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 séparé.2 exploitation d'une "table de hachage distribuée" (DHT). Un DHT est un gros index distribué qui mappe des torrents (identifiés par infohashes) à des listes de pairs (identifiés par leur adresse IP et leurs ports) participant à un essaim pour ce torrent (télé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 qu'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 des 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 à l'infohash. Il avise ces clients qu'il souhaite participer à l'essaim et leur demande les informations de connexion de tous les pairs de leur connaissance qui participent déjà à l'essaim.
Lorsque des pairs téléchargent/téléchargent un torrent en particulier, ils essaient de se parler de tous les autres pairs de leur connaissance qui participent au même essaim de torrent. Cela permet aux pairs de se connaître rapidement, sans soumettre un tracker ou un DHT à des requêtes constantes. Une fois que vous avez appris quelques pairs de DHT, votre client sera en mesure de demander à ces pairs les informations de connexion d’un nombre encore plus grand 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 métadonnées info du torrent, contenant les noms de fichier et la liste de hachage. Une fois que nous avons téléchargé ces informations et vérifié leur exactitude à l'aide du infohash connu, nous sommes pratiquement dans la même position qu'un client qui a commencé avec un .torrent fichier et a obtenu une liste de pairs à partir du suivi inclus.
Le téléchargement peut commencer.
1 Le code d'information est généralement codé en hexadécimal, mais certains anciens clients utilisaient la base 32 à la place. v1 (urn:btih:) utilise directement le résumé SHA-1, tandis que v2 (urn:bimh:) ajoute un préfixe multihash pour identifier l'algorithme de hachage et la longueur du résumé.
2 Il existe deux réseaux DHT principaux: le DHT "principal" plus simple et un protocole plus compliqué utilisé par Azureus.
3 La distance est mesurée par XOR.
Lectures complémentaires
La découverte par les pairs et la découverte des 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 "créés": lors du premier démarrage, un homologue se connecte à une adresse connue (codée en dur) pour extraire une liste des homologues en cours d'exécution. Cela peut être un semis direct comme une connexion à dht.transmissionbt.com comme mentionné dans un autre message ou comme un amorçage indirect, comme cela se fait habituellement avec JXTA, dans lequel l’homologue se connecte à une adresse fournissant uniquement une liste de texte en clair contenant les adresses réseau des autres homologues.
Une fois que la connexion est établie avec le (les quelques) premier (s) premier (s) homologue (s), celui-ci se connecte pour découvrir d'autres homologues (en envoyant des requêtes) et en tient une table. Étant donné que le nombre d'autres homologues peut être énorme, l'homologue connecté ne conserve qu'une partie de la table de hachage distribuée (DHT) des homologues. L'algorithme permettant de déterminer quelle partie de la table doit être maintenue par l'homologue se connectant 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 homologues 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 conçus de manière à constituer une "signature" pour une ressource et à garantir qu'ils identifient de manière unique le contenu demandé parmi tous les pairs. L'homologue qui se connecte envoie ensuite une demande de découverte du lien/de la ressource aimant aux homologues qui l'entourent. La DHT est construite de telle sorte qu’elle aide à déterminer quels pairs doivent être interrogés en premier pour la ressource (pour plus d’informations, consultez Kademlia dans Wikipedia). Si l'homologue demandé ne détient pas la ressource demandée, il "transfère" 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 homologue détient la ressource, il répond avec tous les détails. L’homologue qui se connecte peut ensuite se connecter à l’homologue qui détient 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 sont non directement rattachés aux adresses réseau: ils sont distribués, ce qui fait toute la beauté de ces réseaux hautement évolutifs.
J'étais curieux par la même question moi-même. 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 que 6 fois, en attendant 40 (!) Secondes entre les essais. Je suppose que vous pouvez le tester en supprimant les fichiers de configuration (~/.config/transmission sur Unix), et bloquant toute communication avec dht.transmissionbt.com et voyez ce qui se passe (attendez au moins 240 secondes).
Il apparaît donc que le client a un nœud bootstrap intégré). Bien sûr, une fois entré dans le réseau, il n’a plus besoin de cela bootstrap = nœud plus.
J'ai enfin 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 développeurs, remarquez l'onglet bittorrent.org à droite, puis c'était facile à partir de là. Il est difficile de trouver des liens lorsque vous ne savez pas ce qu'ils portent et beaucoup clique).
Il semble que tous les torrents ont 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 liens aimantés mais il semble que la façon dont un nouveau client trouve des pairs est indéfinie. Certains utilisent peut-être 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 compris que vous demandiez comment fonctionne le système d'aimants. Je pensais juste que vous vouliez savoir comment les parties relatives au protocole BitTorrent ont été générées.
Le hachage indiqué dans l'aimant uri est le hachage d'informations du torrent codé en base32. Le hash info est le sha1 du bloc d'informations codé du torrent.
Ce code python montre comment il peut être calculé.
J'ai écrit une implémentation (très naïve) de C # pour le tester 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 manière de localiser le 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 traqueur. C'est toujours le principal moyen de communication entre 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 aimantés comme un autre moyen d'identifier les torrents de cette manière. Vous n'avez plus besoin de télécharger des fichiers .torrent. L’aimant uri doit encore spécifier le tracker pour 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 alimentée par le torrent qui met à niveau le client (par exemple, il y a un torrent pour uTorrent qui le met à niveau). tant que tout le monde utilise le même client, cela devrait être bien, car vous n'avez pas d'autre choix que de partager la mise à niveau.