Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Libtorrent 2.0 est disponible, une version majeure qui prend en charge BitTorrent v2, SHA-256,
Une nouvelle structure des répertoires et le support des arbres de hachage

Le , par Bill Fassinou

90PARTAGES

9  0 
L’équipe de développement de Libtorrent, l'implémentation open source du protocole de communication pour le partage de fichiers pair-à-pair (P2P) BitTorrent, vient de publier sa version 2.0. Libtorrent 2.0 est une version majeure avec quelques fonctionnalités majeures, principalement la prise en charge de BitTorrent v2. Les autres fonctionnalités comprennent la prise en charge de SHA-256, une nouvelle structure des répertoires, le support des arbres de hachage et des arbres de hachage par fichier, etc. Voici ci-dessus les nouveautés clés de cette nouvelle version.

SHA-256

La fonction de hachage pour les données sur les blocs a été modifiée en SHA-256. L'une des raisons à l’origine de cette modification est que les hachages sont de 32 octets au lieu de 20. Selon l’équipe, dans BitTorrent v2, le dictionnaire d'informations est également calculé par SHA-256, ce qui pose un problème de compatibilité avec la DHT et les trackers, dont les protocoles prévoient des hachages de 20 octets. Pour résoudre ce problème, la DHT et les traqueurs annoncent et recherchent les torrents v2 en utilisant le dictionnaire d'informations SHA-256 tronqué à 20 octets.

Selon l'équipe, c'est l'une des raisons pour lesquelles un protocole v2 a été créé au départ. Cela signifie que fondamentalement, un torrent v2 sera identifié par un hachage différent de celui d'un torrent v1, ce qui créerait toujours un essaim séparé, même lorsque vous partagez les mêmes fichiers.

Les arbres de hachages

Selon l’équipe de Libtorrent, dans BitTorrent v1, les blocs sont hachés et les hachages résultants sont inclus dans le fichier .torrent/metadata (dans le dictionnaire d'informations). Dans la plupart des cas, les hachages de blocs représentent la majeure partie de la taille des fichiers .torrent. Ainsi, pour que la taille du fichier .torrent soit plus raisonnable dans le cas de fichiers volumineux, la taille des blocs peut être augmentée, ce qui veut dire que chaque hachage représente une plus grande partie du fichier .torrent. Cela crée malheureusement un problème.


La raison pour laquelle la taille des blocs est si importante est que si un hachage échoue, il faut télécharger à nouveau une plus grande partie du fichier, jusqu'à ce que le bloc passe le contrôle de hachage. Une vieille idée pour améliorer ces deux mesures est d'utiliser des arbres de hachage merkle pour représenter les pièces de hachage. Cela permet de réduire la taille des fichiers .torrent, car il suffit d'utiliser le hachage de la racine de l'arbre. BitTorrent v2 utilise les arbres de hachage merkle pour les morceaux, mais un protocole autre que celui implémenté dans le tripler.

Cela présente quelques avantages. En premier lieu, les métadonnées du torrent (notamment la partie du dictionnaire d'informations du fichier .torrent) sont beaucoup plus petites. Cela réduit la latence au démarrage lors de l'ajout d'un lien magnétique, car, à présent, moins d'octets sont téléchargés avant que le téléchargement du torrent lui-même ne commence. En second lieu, les données téléchargées peuvent être validées au niveau du bloc. Cela signifie que si un pair envoie des données corrompues, celles-ci peuvent être découvertes immédiatement et seuls 16 kb sont retéléchargés.

Le pair qui a envoyé les données corrompues peut également être identifié avec certitude. L'équipe estime qu'il s'agit d'une grande amélioration par rapport aux heuristiques nécessaires pour identifier le mauvais pair dans la version 1. Enfin, les feuilles des arbres de hachage sont toujours de 16 kb, quelle que soit la taille du bloc. Le concept de taille de bloc existe encore et est toujours utilisé au sein du protocole peer-wire comme il l'est aujourd'hui dans les messages HAVE et REQUEST.

Cela dit, au lieu que les hachages de blocs soient en fait le hachage du contenu du bloc, c'est la racine de l'arbre de hachage du bloc, c'est-à-dire un sous-arbre de l'arbre de hachage complet. Ainsi, dans la version 2, le fichier .torrent doit toujours contenir ces hachages de blocs. Cela permet de distribuer et de stocker les hachages afin qu'ils ne doivent pas être recalculés lors du redémarrage d'un client en cours d'ensemencement. Ils sont également stockés dans l'état de reprise. Par conséquent, la taille du fichier .torrent n'est pas plus petite pour un torrent v2.

Cela se traduit par le fait que le fichier .torrent contient toujours les hachages de blocs. Par contre, le dictionnaire d'informations, représentant la partie nécessaire pour que les liens magnétiques commencent à être téléchargés, est beaucoup plus petit.

Les arbres de hachage par fichier

Selon l’équipe de développement de Libtorrent, BitTorrent v2 utilise non seulement un arbre de hachage, mais il forme un arbre de hachage pour chaque fichier du torrent. Cela a quelques avantages. Le premier est que les fichiers identiques auront toujours le même hachage et pourront être déplacés plus facilement d'un torrent à l'autre (lors de la création de torrents) sans avoir à retaper quoi que ce soit. Dans le même ordre, les fichiers identiques peuvent également être plus facilement identifiés entre les différents essaims, puisque leur hachage de racine ne dépend que du contenu du fichier.

Entre autres avantages de cela, tous les fichiers seront alignés par bloc, c’est-à-dire qu'il y a des fichiers .pad implicites après chaque fichier. Enfin, cela répond à un souhait de longue date d'identifier plus facilement les fichiers en double, ou de trouver des sources multiples de fichiers, parmi les essaims.

Nouvelle structure des répertoires

Comme mentionner plus haut, la plupart du temps, les blocs hachés occupent la majorité de la place dans le dictionnaire d’informations. Les exceptions sont les torrents avec beaucoup de petits fichiers ; alors c'est la liste de fichiers qui utilise le plus d'espace. Dans les torrents v1, les listes de fichiers sont exprimées comme une seule liste de fichiers avec des chemins d'accès complets. Dans un torrent avec une structure de répertoires profonde, ces noms de répertoires seront dupliqués plusieurs fois, ce qui aggrave le problème.

Les torrents v2 remédient à ce problème en utilisant un encodage plus efficace pour la structure des répertoires, avec moins de duplication. Au lieu d'une liste plate, la structure des répertoires est stockée sous forme d'arbre (en utilisant des dictionnaires codés). De ce fait, les noms des répertoires ne sont mentionnés qu'une seule fois.

La rétrocompatibilité

Selon l’équipe, toutes les nouvelles fonctionnalités de BitTorrent v2 qui ne sont pas rétrocompatibles ont été soigneusement baptisées, afin de leur permettre de coexister avec leurs homologues de la version 1. Il est donc possible de créer des torrents hybrides. C'est-à-dire des torrents qui peuvent participer à un essaim de v1 et de v2 en même temps. Un torrent hybride a deux infohaches, un hash SHA-1 v1 et un hash SHA-256 (éventuellement tronqué). Cela forme deux essaims, ou un essaim séparé.

Libtorrent marque les pairs comme supportant ou non la v2. Cette information est également relayée par un nouveau drapeau d'échange de pairs (PEX). Un fichier .torrent hybride comprend les deux hachages de pièces ainsi que les hachages de racines d'arbre pour chaque fichier.

La taille des blocs

Dans les torrents v1, la taille d'un bloc n'est pas limitée par la spécification. Il n'est pas très logique d'avoir un bloc plus petit que la taille du bloc de 16 kb, mais ce n'est pas interdit. La grande majorité des torrents qui sont créés utilisent une taille de blocs à la puissance 2, mais il y a des valeurs qui ne le sont pas, mais qui sont quand même divisibles par 16 kb. Les torrents v2 resserrent les exigences en matière de taille de blocs en exigeant qu'elles soient une puissance de 2 et supérieure ou égale à 16 kb.

Source : Libtorrent 2.0

Et vous ?

Qu'en pensez-vous ?

Voir aussi

FritzFrog infecte des millions de serveurs dans le monde. Considéré comme un botnet P2P de nouvelle génération. Il est difficile à détecter et à supprimer puisqu'il ne dispose pas de serveur C&C

P2P Matrix, un protocole ouvert et un réseau de communication pour la communication décentralisée et chiffrée, une alternative à Slack, WhatsApp, Discord et autres ?

Le créateur de BitTorrent annonce une alternative écologique au Bitcoin, moins gourmande en électricité, plus décentralisée et plus sécurisée

BitTorrent inc. devient propriété de Justin Sun, un entrepreneur qui entend adosser une monnaie cryptographique au célèbre réseau P2P

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de zebul66
Nouveau Candidat au Club https://www.developpez.com
Le 11/09/2020 à 13:57
Je vois une erreur dans l'article. libtorrent est une implémentation du protocole bittorrent.

Il y en a d'autres et les client bittorrent les plus connus ont leur propre implémentation du protocole et n’utilisent pas cette librairie/implémentation (sauf deluge et qbittorrent)

libtorrent n'est pas une librairie officielle lié au protocole.
0  0