Because it is somewhat related to ICH (Intelligent Corruption Handling) I will quote the our helpfile on it first:
Quote
Normally, corrupted chunks must be completely redownloaded. ICH tries to reduce the amount of data that needs to be redownloaded by rechecking it everytime new data for this part is received and thus saves time if a corruption is detected.
Statistically if one byte in a part is corrupted, ICH saves 50% of redownloading on average. In the best case it saves 99% (if the first byte we redownloaded was the corrupted one) and in the worst case it saves 0% (if the last byte we redownload for this part was the corrupted one). However if more than one position is corrupted ICH becomes more likely to be uneffective for this part. It also doenst helps if other malicious clients spread wrong data, because it is very likely that this part gets corrupted again and again.
Now what is AICH (Advanced Intelligent Corruption Handling)?
This system uses a complete different approach. It consists of a new hashsetset which is build from 180KB blocks and put together in a Hashtree. The used hashalgorithm is SHA1 (160Bits).
eMule creates this new hashset for all your shared files and stores it in the known2.met. Because the size of those hashset can be quite big - about 24 000 hash for a 4GB files and 48 000 hashs for a complete hashtree (which can be calculated from those 24K hashs), it is not stored in memory but only in this file and read on demand. When eMule has stored the full hashset it propagates the root/masterhash to other downloading clients.
Now if your client is downloading a file and detects a corrupted part it will request a recoverypacket from a random client which has a full AICH hashset. This recoverypacket consists of up to 69 hashs (53 for the partdata and 1-16 which make it possible to verify those 53 hashs against the masterhash which we trust). When your client received this packet and verified that the hashs fit to the roothash it checks all 180KB blocks of your corrupted part against the hashs it received and restores those 180KB blocks which have no corruption. This means if we assume that one byte of your 9.28MB part was corrupted, AICH would restore all blocks except the one were the corrupted byte is and your would have to redownload only this 180KB block.
In your log this would look like:
09.09.2004 02:43:43: Downloaded part 6 is corrupt ([file])
09.09.2004 02:43:46: AICH successfully recovered 8.22 MB of 9.28 MB from part 6 for [file]
In this example there were at least 6 corruptions in one part on different positions.
Why should you use Links with AICH Hashs?
One important thing is that we have to trust the AICH masterhash. IF this hashs is wrong (aka fits not to the md4 hash), it can cause serious problems while downloading and makes at least AICH for this file unusable (even tho on normal condtions you would still be able to finish a file with a wrong AICH hash).
eMule has two trustlevels when downloading a file.
If you didn't used a AICH link, eMule will use the hash which it receives from other clients, if certain conditions are met: At least 10 unique IPs have to sent us this hash and 92% of all clients which sent a hash have to agree on the same one. This hash gets the lowest trustlevel, is not saved when restarting eMule and you can't create AICH links with such a hash.
For rare files or a new released file with very few complete sources it can happen that eMule will not be able to trust any hash. Another case would be when some malicious client spreads wrong AICH hashs, so that eMule can't trust any hash or even worse trusts a bad hash. In all those cases AICH will be useless for this file.
Therefore the better solution is to use a link with an attached AICH hash. This hash is trusted from the beginning, it will be saved and you can also create filelinks with this hash.
AICH hashlinks are also backward compatible to earlier eMule versions (which will just ignore the additional hash).
Thats all