Le principe du hachage des réseaux de P2P comme emule et edonkey



De nombreux réseaux de P2P utilisent la technique du hachage (Hashing). Le hachage d'un fichier peut être comparé à une empreinte digitale. Cette technique permet une identification, unique et certaine, du contenu de ce fichier, en n'utilisant qu'une faible quantité de données.

Le protocole eDonkey/eMule utilise l'algorithme MD4 (message digests 4), dont la longueur est fixe de 16 octets (128 bits). Quelle que soit la taille du fichier, 10 octets, 20 kilo octets ou 1,5 giga octets, la valeur de hachage fait toujours 16 octets. Deux fichiers de même taille mais dont les contenus diffèrent ont des valeurs de hachage différentes (en théorie, car il y a toujours un très petit risque que deux contenus distincts produisent le même hachage. Toutefois, cet algorithme autorise 2^128 valeurs).

Le hachage du fichier représente donc l'identifieur ultime de son contenu.
Hachage des fichiers (Hash, File ID)

Le protocole prévoit que pour être mis en partage, chaque fichier doit être "découpé" en morceaux élémentaires. Ces entités élémentaires ont une taille de 9,28 Mo*. Seuls les morceaux complets et non corrompus sont partagés.
Ainsi, chaque fois qu'eMule termine le téléchargement d'un morceau, elle s'assure de l'absence de corruption des données. S'il est valide, il est proposé en partage.

Commentle morceau est-il reconnu sur le réseau ?

Le morceau, tout comme n'importe quel fichier est reconnu, non par son nom (un morceau n'a pas de nom), mais par la valeur de son hachage. eMule applique l'algorithme MD 4 sur les données constitutives de chaque morceau élémentaire complet. Le résultat de cette opération est une valeur de hachage, unique.

Qu'est-ce que la valeur de hachage d'un fichier ?

C'est la valeur obtenue en appliquant un algorithme MD4 aux valeurs de hachage de l'ensemble des morceaux qui le constituent.

Table de hachage

Lorsque l'on ajoute un téléchargement à eMule, la première source qui envoie des données envoie pour commencer la table de hachage (ou hash set) du fichier. C'est l'ensemble des valeurs de hachage de tous les morceaux qui constituent le téléchargement, la position précise du début et de la fin de chacun de ces morceaux et la valeur de hachage du fichier lui-même. Le fichier part.met est alors créé, en fonction des instructions de cette table. Le part.met est donc le plan permettant à eMule la construction du téléchargement. Grâce à lui, elle sait si le morceau reçu est valide ou non (en comparant la valeur de son hachage à celui de la table de hachage) et où il doit se placer. Lorsque le téléchargement est achevé, toutes les valeurs de hachage des morceaux ont été vérifiées. Il ne reste plus à eMule qu'à calculer la valeur de hachage du fichier lui-même, en appliquant l'algorithme MD4 aux valeurs de tous les morceaux élémentaires. Puis à la comparer à la valeur reçue dans la table de hachage. Si elle est identique, le fichier est transféré dans le répertoire de réception et partagé. Voir La finalisation.
Autres valeurs de hachage

L'algorithme MD4 est aussi utilisé pour générer d'autres identifiants nécessaires à eMule. Ainsi, chaque utilisateur du réseau est reconnu par la valeur de hachage qui lui est attribuée une fois pour toute (sauf mauvaise manipulation), lors du premier lancement d'eMule et qui est sauvegardée dans le fichier preferences.dat.

Quel que soit le pseudo que vous utilisez sur le réseau et même si vous ne modifiez pas le pseudo par défaut, ce qui est déconseillé, les autres clients vous reconnaissent infailliblement. Heureusement pour vous, car vous pouvez ainsi bénéficier des crédits que vous avez accumulé chez eux. Toutefois, dans ce cas, l'identification est sécurisée grâce à une clé de cryptage contenue dans le fichier cryptkey.dat.

--------------------------
* Certains morceaux complets ont une taille inférieure à 9,28 Mo. Les fichiers de taille inférieure à 9,28 Mo ne sont constitués que d'un seul morceau. Le dernier morceau d'un fichier a une taille correspondant au reste de la division de la taille totale du fichier par 9,28 Mo.

Aintzane, tellement aveuglée par tes idées que tu n'as même pas retenu l'essentiel de ce que je disais. Bon, c'est vrai que c'était un peu long, mais en gros je disais qu'on pouvait peut être limiter la casse en informant mieux l'utilisateur, car ça : c'est possible.

Qui te fait dire que ça ne sert plus à rien de faire quoi que ce soit ? S'il est bientôt impossible de télécharger, et bien tant pis, on vivra sans. Mais je ne vois pas pourquoi ça aurait de l'influence sur notre quotidien d'aujourd'hui.

Et je sais que ce n'est pas un problème essentiel, mais de là à insinuer que ma remarque est inutile, c'est pas très sympathique à l'égard de quelqu'un qui cherche juste à faire profiter à tout le monde d'éventuelles améliorations.

Scratchy a écrit :
S'il est bientôt impossible de télécharger, et bien tant pis, on vivra sans.
Mais je ne vois pas pourquoi ça aurait de l'influence sur notre quotidien d'aujourd'hui.

Maintenant, si chaque problématique évoquée, qui pourrait être partiellement résolue avec un nouveau plugin eChanblard, se voit répondre à peu près dans ces termes : Bin si t'es si malin, t'as qu'à le faire toi même.

Il est alors peu probable que ce mode de pensées participe à la croissance du forum. Ou bien il faudrait penser à indiquer en face de la section "Évolutions et Particularités" : Seuls les programmeurs/développeurs sont habilités à emettre des idées. Ou encore : idées acceptées, moyennant 8h de bénévolat hebdomadaire sur ce forum.

Je pense que certains moderateurs, voire tous, passent encore plus de temps que ça à aider les plus débutants comme les plus chevronnés. Je vous en remercie, d'autant que je n'aurais pas le temps de le faire.

Mais si toute idée alors émise pas quelqu'un comme moi, qui ne passe autant de temps que vous sur le forum, se voit boulée au nom d'une participation considérée peu active, ça remet simplement en cause l'emission même des idées.