Il faut savoir que la plupart des protocoles fonctionnent de la facon suivante, pour calculer la signature d'un fichier:
On decoupe le fichier en "chunks" (9.5 Mo pour mldonkey, ~256 Ko pour bittorrent). On calcule le hash (MD4, SHA1...) de chaque chunk. La signature du fichier est le hash de la concatenation des hashs de tous les chunks.
Grace a cette methode, on peut verifier l'integrite de bouts de fichier qu'on possede deja, avant d'avoir l'integralite du fichier. Cela permet de commencer a uploader alors qu'on n'a pas tout downloader, ainsi que de detecter qu'un "peer" nous uploade n'importe quoi (Et grace au "mods" emule, y'en a plein).
A partir de la, c'est facile de downloader sur plusieurs reseaux:
On recherche sur tous les reseaux, les fichiers contenant la chaine "redhat" et de taille 762 154 782 Octets. Il est hautement probable que tous ces fichiers sont les memes, a quelques mutations pres.
On commence a downloader tous ces fichiers. Pour donner un exemple, je vais les nommer:
* Je suppose que deux fichiers repondaient aux criteres precedants sur le reseau edonkey. Je les appelle E1 et E2.
* Sur Faststrack, il y en avait 3: F1, F2 et F3.
* Sur Bittorrent, un seul: B1
* ...
Parmi tous ces fichiers, j'en choisis un qui est la reference. On va dire que c'est E1.
Je detecte que j'ai telecharge sur F1, l'equivalent d'un chunk de E2. Je calcule alors la signature edonkey de ce chunk (que j'ai telecharge sur Fasttrack) et je me rends compte que c'est la signature attendue. Je marque alors ce chunk comme telecharge pour E2.
Et ainsi de suite...
Quand mon fichier de reference (E1) est termine, ben je suis content. C'est celui que je voulais a la base. J'interromps alors tous les autres car j'ai fini.
Ce systeme marche, meme si les fichiers ne sont pas exactement les memes. En general, ce sont toujours des mutations d'une meme source. Par exemple E1 et E2 auront exactement les memes chunks, sauf 1. Cela sera donc tres rentable de downloader des bouts de E1 sur E2. Comme E1 est la reference, on peut meme decider de ne jamais downloader le chunk qui differe entre E1 et E2 (petite optimisation facile a faire). Si E1 et F1 sont differents, on ne peut pas s'en rendre compte (a cause du schema de signature qui n'est pas le meme, vu qu'ils vivent sur des reseaux differents). L'optimisation n'est donc pas faisable. En pratique, c'est pas genant car ils vont differer sur un petit bout.
Notons que depuis la version 2.4 (et peut-etre avant, voir le Changelog), mldonkey est deja capable de se rendre compte que certains fichiers edonkey partagent les memes chunks. Quand il a downloader un chunk commun sur l'un, il le recopie sur l'autre (fichier).
[^] # Re: Logiciel de pirates
Posté par thoran . En réponse à la dépêche Mldonkey 2.5.3 est sorti. Évalué à 5.
On decoupe le fichier en "chunks" (9.5 Mo pour mldonkey, ~256 Ko pour bittorrent). On calcule le hash (MD4, SHA1...) de chaque chunk. La signature du fichier est le hash de la concatenation des hashs de tous les chunks.
Grace a cette methode, on peut verifier l'integrite de bouts de fichier qu'on possede deja, avant d'avoir l'integralite du fichier. Cela permet de commencer a uploader alors qu'on n'a pas tout downloader, ainsi que de detecter qu'un "peer" nous uploade n'importe quoi (Et grace au "mods" emule, y'en a plein).
A partir de la, c'est facile de downloader sur plusieurs reseaux:
* Je suppose que deux fichiers repondaient aux criteres precedants sur le reseau edonkey. Je les appelle E1 et E2.
* Sur Faststrack, il y en avait 3: F1, F2 et F3.
* Sur Bittorrent, un seul: B1
* ...
Parmi tous ces fichiers, j'en choisis un qui est la reference. On va dire que c'est E1.
Ce systeme marche, meme si les fichiers ne sont pas exactement les memes. En general, ce sont toujours des mutations d'une meme source. Par exemple E1 et E2 auront exactement les memes chunks, sauf 1. Cela sera donc tres rentable de downloader des bouts de E1 sur E2. Comme E1 est la reference, on peut meme decider de ne jamais downloader le chunk qui differe entre E1 et E2 (petite optimisation facile a faire). Si E1 et F1 sont differents, on ne peut pas s'en rendre compte (a cause du schema de signature qui n'est pas le meme, vu qu'ils vivent sur des reseaux differents). L'optimisation n'est donc pas faisable. En pratique, c'est pas genant car ils vont differer sur un petit bout.
Notons que depuis la version 2.4 (et peut-etre avant, voir le Changelog), mldonkey est deja capable de se rendre compte que certains fichiers edonkey partagent les memes chunks. Quand il a downloader un chunk commun sur l'un, il le recopie sur l'autre (fichier).