Difference between revisions of "AICH"
Vollstrecker (Talk | contribs) m (Added Version Tag) |
Vollstrecker (Talk | contribs) m (Removed Version Tag) |
||
| Line 32: | Line 32: | ||
Please notice that as long as the AICH method can be applied to a file, [[ICH]] will not be used for that file. | Please notice that as long as the AICH method can be applied to a file, [[ICH]] will not be used for that file. | ||
| − | |||
| − | |||
| − | |||
| − | |||
Revision as of 09:35, 29 June 2008
English | German
Contents
Description
ICH's success has no point to be discussed about, but it comes to an end where being able to actually know which exact part of the chunk is corrupt would make life easier. This comes specially significant when several chunks are corrupt. AICH (Advanced Intelligent Corruption Handler) takes part in this problem and allows aMule, or any client supporting it, to actually know which portions of the chunk is corrupt.
Definitions
Each chunk is divided into 53 parts (52x 180KB and 1x 140KB) and each of these parts is hashed using the SHA1 algorithm. Each of these hashes is called a Block Hash. By combining pairs of Block Hashes (i.e. each part with the part next to it) aMule will get a whole tree of hashes (this tree which is therefore a hashset made of all of the other Block Hashes is called the AICH Hashset). Each hash which is neither a Block Hash nor the Root Hash, is a Verifying Hash. The hash at the top level is the Root Hash and it is supposed to be provided by the ed2k link when releasing.
The actual work
When a chunk is known to be corrupt, aMule will try to get an AICH Hashset from a client sharing that file which is complete, meaning the file at the client side is complete. It will ask for the all hashes of the 53 parts in the corrupt chunk and the necessary Verifying Hashes to complete the AICH Hashset tree up to the Root Hash.
Once it gets the Block Hashes and the Verifying Hashes, it builds up the tree to get the Root Hash and check if it's the same as the Root Hash the original ed2k links provided. If it is, those Block Hashes will be considered as reliable. If it isn't, then the Block Hashes and Verifying Hashes will be dropped and considered fakes.
Once the Block Hashes are considered reliable, each 180KB part in the corrupted chunk will be hashed (using the SHA1 algorithm) in order to compare the resulting hash with the recieved Block Hashes. If they are the same, then that part is not corrupted, so there's no need to redownload it. If they're not the same, then that part is corrupted and it will be redownloaded.
How is the Root Hash spread?
The ideal way to spread the Root Hash is through the ed2k link. However, files are more frequently downloaded through the search feature of the eD2k client. Also, the ed2k link might not include the Root Hash in its URL. In such cases an alternative method is used to get the file's Root Hash.
Clients ask other clients for the Root Hash. If at least 10 other clients send you the same Root Hash and that is 92% or more of the total Root Hashes received, that Root Hash will be considered as reliable for the current session only. It will not be stored anywhere on disk and will only be kept in memory. Also, it will not be shared with any other client who asks for it.
When the file download is completed, the Root Hash will be calculated, with the whole AICH Hashset, stored in ~/.aMule/known2.met and shared with any client who asks for it.
Storing the AICH Hashset
Once a file has been completly downloaded, aMule builds its complete AICH Hashset and stores it in ~/.aMule/known2.met so whenever a client asks for it, it can provide it without having to recalculate it every time.
Please notice that as long as the AICH method can be applied to a file, ICH will not be used for that file.
