DHT网络 学习笔记

原文见：http://codemacro.com/2013/05/19/crawl-dht/

【学习笔记】

原bt下载依赖于tracker，后者不存储资源本身，但存储着拥有资源（片段）的peer列表。这样一来，tracker即扮演着中心节点的角色，一旦移除，会因为无法找到其它peer而下载失败。

DHT网络致力于通过去中心化解决上述问题，在tracker失效的情况下仍然能找到其它peer。

首先，每个主机都被抽象为一个节点，通过hash算法，可以得到一串类似于UUID的坐标。资源也是一样。

有了坐标，就可以计算节点与节点之间，或节点与资源之间的距离。注意这个距离并非指物理距离，而是为了便于给节点和资源均匀分组所计算出的一个指标（例如，距离可以是取两个坐标异或的值）。距离近的节点就落到了一起，共同扮演临近资源的tracker的角色。

每个节点都存有一张路由表（hash表），记录着已知的节点，特别是较临近节点的相关信息（如节点的ip地址，扮演哪些资源的tracker即资源对应的peer列表）。注意路由表空间受限，会优先存储较近的节点和资源。

在收到查询节点的请求后，随即搜索路由表，命中尤佳，miss则返回路由表中最为靠近目标的节点。

查询资源（即资源对应的peer列表）也是类似，搜索路由表，miss则返回路由表中最为靠近目标资源的节点。

经过几次递归查询后，会迅速逼近以致命中目标，于是下载开始了。开始下载的节点会向沿途所有查询并获得反馈的节点汇报自己成为了该资源的peer。后者会视情况更新它们的路由表。

而发布资源的过程，即简单地查找距资源坐标最近的节点们，并向其汇报即可。

有个问题，若节点散布得不够均匀，极端情况下与某资源最靠近的几个节点其实都相距甚远，若这些节点的路由表容量有限，根据距离优先的原则踢除了该资源的peer信息，以致无法下载。会出现这样悲催的局面吗，目前的实现是如何规避的？