Je code une implémentation P2P que j'aimerais rendre décentralisée. Cependant, j'ai du mal à comprendre comment DHT dans des protocoles comme BitTorrent fonctionne.
Comment le client sait-il où se trouvent les pairs s'il n'y a pas de traqueur? Les pairs sont-ils stockés dans le fichier torrent lui-même?
Avec les torrents sans traqueur/DHT, les adresses IP des pairs sont stockées dans le DHT en utilisant l'infohash du BitTorrent comme clé. Puisque tout ce qu'un traqueur fait essentiellement est de répondre aux demandes de mise/enlèvement, cette fonctionnalité correspond exactement à l'interface qu'un DHT (table de hachage distribuée) fournit : elle vous permet de rechercher et de stocker des adresses IP dans le DHT par infohash.
Ainsi, une demande de "get" rechercherait un infohash BT et renverrait un ensemble d'adresses IP. Un "put" stocke une adresse IP pour un infohash donné. Cela correspond à la demande d'"annonce" que vous feriez sinon au traqueur pour recevoir un dictionnaire d'adresses IP de pairs.
Dans un DHT, les pairs sont assignés de manière aléatoire pour stocker des valeurs appartenant à une petite fraction de l'espace clé ; le hachage assure que les clés sont distribuées de manière aléatoire à travers les pairs participants. Le protocole DHT (Kademlia pour BitTorrent) garantit que les demandes de mise/enlèvement sont routées efficacement vers les pairs responsables de maintenir les listes d'adresses IP d'une clé donnée.
Le port est inclus avec l'adresse IP du pair: bittorrent.org/beps/bep_0005.html#contact-encoding
La théorie générale peut être trouvée dans l'article de wikipedia sur Kademlia. La spécification du protocole spécifique utilisé dans bittorrent se trouve ici : http://wiki.theory.org/BitTorrentDraftDHTProtocol
Ce qui se passe avec Bittorrent et un DHT, c'est qu'au début Bittorrent utilise les informations intégrées dans le fichier torrent pour se rendre soit à un traqueur (tracker) soit à l'un des nœuds du DHT. Ensuite, une fois qu'il trouve un nœud, il peut continuer à en trouver d'autres et persister en utilisant le DHT sans avoir besoin d'un traqueur centralisé pour le maintenir.
L'information originale amorce l'utilisation ultérieure du DHT.
Les nœuds DHT ont des identifiants uniques, appelés ID de nœud. Les ID de nœud sont choisis de manière aléatoire dans le même espace de 160 bits que les hachages d'informations BitTorrent. La proximité est mesurée en comparant les tables de routage des ID de nœud, plus le nœud est proche, plus les détails sont nombreux, ce qui donne un résultat optimal
Alors, qu'est-ce qui les rend plus optimaux que leur prédécesseur "Kademlia" qui utilisait des entiers non signés simples : distance(A, B) = |A xor B| Les valeurs plus petites sont plus proches. XOR. En plus de ne pas être sécurisé, sa logique était défectueuse.
Si votre client prend en charge le DHT, 8 octets sont réservés dans lesquels se trouve 0x09 suivi d'une charge utile de 2 octets avec le port UDP et le nœud DHT. Si le handshake est réussi, ce qui précède se poursuivra.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
