I'm about to go off and see if I can extend the protocol in mldonkey in a backwards-compatible manner. My problem is that I find the granularity of the hash is insufficient.
My dev question is, before I go implement this in mldonkey, does emule have a similar project going on that I should be aware of? I don't think we want another zillion and a half protocol extensions to complicate everyone's life like the source exchange protocols.
Here is a short description of my protocol extension:
For each file A of size larger than 10 KB (say), I will create a file A.hash. This A.hash file will contain an array of md5 or sha hashes of file A, each hash covering only 10KB of file A. The usual md5 hash of file A will also be included in file A.hash. A client aware of this extension would never show both A and A.hash in a search window, of course. If the A.hash file is available, it is downloaded first. Then, the client knows much more precisely what the final file should look like, and so can decide whether fragments are corrupted early on. The same usual 9MB granularity hashing is left in for backwards-compatibility. As an additional note, if A.hash is also of size more than 10KB (say), then a hash of it will be generated, although I would probably call it A.hash1 instead of A.hash.hash, and so on. One would first get the very last hash file, then work one's way backwards.
I apologize for not contributing this extension to emule, but I do not have access to MSVS7.net.
My main motivation is to minimize the effect of adversarial clients who send bogus information to corrupt large chunks of files. If every 10KB is checkable separately, it makes intentional corruption much more difficult and detectable.
I hope I found the proper channel, I can't figure out who I need to contact.
loisel at math dot mcgill dot ca
PS (Edit -loisel): Thanks for pointing that out, VQB. (Please read the Forum Rules. Edit -VQB)
This post has been edited by loisel: 24 February 2003 - 07:27 AM