AICH

標準的 ICH 是相當有效的雖然它有它的限制只在整個 9.28 MB 能被驗證並且沒有完美的區塊. 假如超過一個以上的位置是損壞或是惡意客户端一再的散佈損壞的資料或甚至是假的 部分哈希值, ICH 再也沒有能力去處理.

在這裏 AICH 將會考慮完全的完整資料用一個最小重新下載量或者由建立非常完美的哈希值來管理.

根哈希值, 區塊哈希值 & AICH 片段哈希值

這次我們的起點是在一個文件的 9.28 MB 部分. 每個部分是被分割成 180 KB 的區塊, 在每個部分將會產生 53 個區塊並且每個區塊使用 SHA1 切細運算方式計算出哈希值. 那些值稱為 區塊哈希值 並且根據一個低標準的一個完整 AICH 片段哈希值.

在上面的圖片是顯示一個完整的哈希值樹狀圖如何建立在一個完整 4 部分文件的區塊. 每個部分包含 53 個區塊產生出 212 個 區塊哈希值 其中建立在一個切細樹狀的第七層直到 根哈希值 到達時. 這整個樹狀稱為 AICH 片段哈希值.

綠色和黃色點顯示小型的 區塊哈希值 到 根哈希值 之數學相關性. 這個表示假如我們有一個可信任的根哈希值整個樹狀能被逆向的來驗證它.

eMule 能建立包含根哈希值的鏈接, 例如

ed2k://|file|name|12043984|6744FC42EDA527B27F0B2F2538728B3E| h=A2NWOTYURUU3P3GCUB6KCNW3FTYYELQB|/

其中 h= 是 根哈希值. 由提供一個可信賴的 根哈希值 併發布它應該能有明顯的改善文件的損壞抵抗性. 閲讀 根哈希值的信任

無論何時 eMule 在一個部分偵測到一個損壞它需要用一個完整 AICH 哈希值資料從隨便一個客户端中取得一個還原封包. 這個還原封包包含在切細樹狀整體損壞部分的全部 53 個 區塊哈希值 和一個 驗證哈希值 的號碼. 上面圖片顯示一個 4 部分文件的一個還原封包. 驗證哈希值 的號碼是由文件的分割部分數量來決定 (2^x ＞= '部分數量', 用 x = 驗證哈希值號碼).

接收還原封包之後 eMule 檢查 驗證哈希值 逆向確認它的根哈希值. 假如它們相符, eMule 從還原封包的 區塊哈希值 逆向檢查損壞部分的全部 53 個區塊. AICH 能還原全部區塊用它們的 區塊哈希值 逆向相符來讓只有損壞的區塊重新下載.

在記錄中一個成功的還原看起來會像下面列出的:

09.09.2004 02:43:43: 已下載部分 6 損壞了 :( [file])

09.09.2004 02:43:46: AICH 成功的還原 8.22 於 9.28 從部分 6 於 [file]

最佳的方式是從有 根哈希值 的鏈接來下載. 假定這個鏈接的來源是可信任的根哈希值而一但受信任將會把這個文件的根哈希值儲存在磁盤.

假如不是由鏈接提供的根哈希值而是由文件的來源送出的 eMule 也會去信任這根哈希值. 它只會在一個 根哈希值 最少 10 個不同的來源送出相同的值和最少全部 92% 的來源同意這個值才會去相信它是真的. 因為這個 根哈希值 不是那麼可靠它只有效於目前工作階段並且不能儲存也不能用 根哈希值 建鏈接.

一旦 eMule 建立整個 AICH 片段哈希值, 例如:文件已經完成, 它將開始傳播 根哈希值 給其他的客户端.

· 新釋放或罕見的文件將也許沒有足夠的完整來源來產生一個可信任的 根哈希值. 建議釋放文件時包含這個哈希值.

· 在一般情況下假如在那裏沒有 根哈希值 或甚至是一個偽造的 eMule 將能夠成功下載並且完成這個文件. 而 AICH 特性不能使用在這種情況.

· 如同 AICH 片段哈希值能非常大他們不儲存在內存但存在 known2.met 並且只能做讀取需求.

· AICH 將只能在 eMule 客户端 v.44a 及更新版本有效但保留舊客户端的向下相容性.