电驴文件损坏的处理问题

来源:岁月联盟 编辑:zhu 时间:2008-07-28
电驴文件损坏的处理问题内容简介:eMule 使用各种的方式来确保文件在网络共享及下载没有错误. 万一错误发生, 称为损坏, eMule 有进阶功能以最小的额外重新下载资料量来修正这个损坏. 文件哈希值和 ICH - 智慧型损坏处理 文件哈希值, 部分哈希值 片段哈希值 在 eMule 使用各种的方式来确保文件在网络共享及下载没有错误. 万一错误发生, 称为损坏, eMule 有进阶功能以最小的额外重新下载资料量来修正这个损坏.

文件哈希值和 ICH - 智慧型损坏处理

文件哈希值, 部分哈希值 & 片段哈希值
在网络共享的每个文件有一个独一无二的识别值是由 MD4 密码数学运算所建立. 这个值称为文件哈希值并且每个标准的 eD2k 链接都有包含, 例如

ed2k://|file|name|12043984|6744FC42EDA527B27F0B2F2538728B3E|/

其中 6744FC42EDA527B27F0B2F2538728B3E 是文件哈希值以确定这个文件在整个网络是独一无二的被识别出.
这个 文件哈希值 是将文件划分为 9.28 MB 为一个部分所计算出来. 每个部分的部分哈希值也是使用相同的 MD4 运算方式计算出来. 那些 部分哈希值, 称为 片段哈希值, 并且它是使用来计算出最终的文件哈希值. 例如一个 600 MB 文件被划分为 65 个部分每个部分都有它自己的 部分哈希值 而它是用来建立最终的 文件哈希值.
为确保 eMule 总是接收到正确的一个特别的链接能包含片段哈希值, 例如

ed2k://|file|name|12043984|6744FC42EDA527B27F0B2F2538728B3E| p=264E6F6B587985D87EB0157A2A7BAF40:17B9A4D1DCE0E4C2B672DF257145E98A|/

其中 p= 值表示 片段哈希值. 每个 部分哈希值 是由 “:” 来区隔. 这个文件大小为 12043984 位元组 (=11.49 MB) 这表示它有一个完整的 9.28 部分和剩下的到 11.49 MB 部分为二个 部分切细片段.

ICH 智慧型损坏处理
无论何时 eMule 完成某一个部分它将会被检查, 假如下载的资料和部分哈希值一样这个将成为已完成部分. 如果是, 这个部分会提供上传来帮助文件的散布.
假如不是, 一个损坏发生且这部分会再次下载. 为避免下载全部 9.28 MB, ICH 从这部分的开头 180 KB 重新下载并且再次检查部分是否完整. 假如不是, 下一个 180 KB 会再下载, 并再次检查. 直到部分哈希值正确为止. 最佳情况下假如损坏只在部分的开头 eMule 只再次下载 180 KB. 最差的情况可能会整个重新下载. 在部分的损坏 ICH 平均可节省 50%.

AICH - 进阶智慧型损坏处理
标准的 ICH 是相当有效的虽然它有它的限制只在整个 9.28 MB 能被验证并且没有完美的区块. 假如超过一个以上的位置是损坏或是恶意客户端一再的散布损坏的资料或甚至是假的 部分哈希值, ICH 再也没有能力去处理.
在这里 AICH 将会考虑完全的完整资料用一个最小重新下载量或者由建立非常完美的哈希值来管理.

根哈希值, 区块哈希值 & AICH 片段哈希值

这次我们的起点是在一个文件的 9.28 MB 部分. 每个部分是被分割成 180 KB 的区块, 在每个部分将会产生 53 个区块并且每个区块使用 SHA1 切细运算方式计算出哈希值. 那些值称为 区块哈希值 并且根据一个低标准的一个完整 AICH 片段哈希值.
在上面的图片是显示一个完整的哈希值树状图如何建立在一个完整 4 部分文件的区块. 每个部分包含 53 个区块产生出 212 个 区块哈希值 其中建立在一个切细树状的第七层直到 根哈希值 到达时. 这整个树状称为 AICH 片?喂?V?.
绿色和黄色点显示小型的 区块哈希值 到 根哈希值 之数学相关性. 这个表示假如我们有一个可信任的根哈希值整个树状能被逆向的来验证它.
eMule 能建立包含根哈希值的链接, 例如

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

其中 h= 是 根哈希值. 由提供一个可信赖的 根哈希值 并发布它应该能有明显的改善文件的损坏抵抗性. 阅读 根哈希值的信任

从一个损坏还原
无论何时 eMule 在一个部分侦测到一个损坏它需要用一个完整 AICH 哈希值资料从随便一个客户端中取得一个还原封包. 这个还原封包包含在切细树状整体损坏部分的全部 53 个 区块哈希值 和一个 验证哈希值 的号码. 上面图片显示一个 4 部分文件的一个还原封包. 验证哈希值 的号码是由文件的分割部分数量来决定 (2^x >= ‘部分数量’, 用 x = 验证哈希值号码).
接收还原封包之后 eMule 检查 验证哈希值 逆向确认它的根哈希值. 假如它们相符, 电驴从还原封包的 区块哈希值 逆向检查损坏部分的全部 53 个区块. AICH 能还原全部区块用它们的 区块哈希值 逆向相符来让只有损坏的区块重新下载.
根哈希值的信任
最佳的方式是从有 根哈希值 的链接来下载. 假定这个链接的来源是可信任的根哈希值而一但受信任将会把这个文件的根哈希值储存在磁盘.
假如不是由链接提供的根哈希值而是由文件的来源送出的 eMule 也会去信任这根哈希值. 它只会在一个 根哈希值 最少 10 个不同的来源送出相同的值和最少全部 92% 的来源同意这个值才会去相信它是真的. 因为这个 根哈希值 不是那么可靠它只有效于目前工作阶段并且不能储存也不能用 根哈希值 建链接.
一旦 电驴建立整个 AICH 片段哈希值, 例如:文件已经完成, 它将开始传播 根哈希值 给其他的客户端.

注意:
• 新释放或罕见的文件将也许没有足够的完整来源来产生一个可信任的 根哈希值. 建议释放文件时包含这个哈希值.
• 在一般情况下假如在那里没有 根哈希值 或甚至是一个伪造的电驴将能够成功下载并且完成这个文件. 而 AICH 特性不能使用在这种情况.
• 如同 AICH 片段哈希值能非常大他们不储存在内存但存在 known2.met 并且只能做读取需求.
• AICH 将只能在 eMule 客户端 v.44a 及更新版本有效但保留旧客户端的向下相容性.