出处：http://www.cnblogs.com/gnuhpc/
P2P的一个常见问题是如何高效的定位节点，也就是说，一个节点怎样高效的知道在网络中的哪个节点包含它所寻找的数据，如下图：
对此，有三种比较典型的来解决这个问题。
Napster：使用一个中心服务器接收所有的查询，服务器告知去哪下载其所需要的数据。存在的问题是中心服务器单点失效导致整个网络瘫痪。
Gnutella：使用消息洪泛（message flooding）来定位数据。一个消息被发到系统内每一个节点，直到找到其需要的数据为止。当然，使用生存时间（TTL）来限制网络内转发消息的数量。存在的问题是消息数与节点数成线性关系，导致网络负载较重。
SN型：现在大多数采用所谓超级节点（Super Node），SN保存网络中节点的索引信息，这一点和中心服务器类型一样，但是网内有多个SN，其索引信息会在这些SN中进行传播，所以整个系统的崩溃几率就会小很多。尽管如此，网络还是有崩溃的可能。
现在的研究结果中，Chord、Pastry、CAN和Tapestry等常用于构建结构化P2P的分布式哈希表系统（Distributed Hash Table，DHT）。
DHT的主要思想是：首先，每条文件索引被表示成一个(K, V)对，K称为关键字，可以是文件名（或文件的其他描述信息）的哈希值，V是实际存储文件的节点的IP地址（或节点的其他描述信息）。所有的文件索引条目(即所有的（K, V）对)组成一张大的文件索引哈希表，只要输入目标文件的K值，就可以从这张表中查出所有存储该文件的节点地址。然后，再将上面的大文件哈希表分割成很多局部小块，按照特定的规则把这些小块的局部哈希表分布到系统中的所有参与节点上，使得每个节点负责维护其中的一块。这样，节点查询文件时，只要把查询报文路由到相应的节点即可（该节点维护的哈希表分块中含有要查找的(K,V)对）。
这里介绍的Chord算法就是解决网络内节点定位问题的一种P2P协议。它通过多个节点跳转找到我们所查找的资源：
我们先看看它是如何进行的，随后再总结其特点和操作特征，以及一些实现。
1.Chord里面的基本要素
节点ID：NID（node identifier），表示一个物理机器，m位的一个数字（m要足够大以保证不同节点的NID相同的几率小的可以忽略不计），由节点机器的IP地址通过哈希操作得到。
资源ID；KID（key identifiers），原为键ID，其实际表示一个资源（因为Key与一个资源value哈希绑定），故在本文中统称资源ID（这样比较直观），m位的一个数字（m要足够大以保证不同资源的KID相同的几率小的可以忽略不计），由Key通过哈希操作得到。
常哈希函数：较之一般哈希函数，节点的加入和离开对整个系统影响最小，另外还有一些优势在此不赘述。在Chord中使用SHA-1来进行常哈希计算。
Chord环：Chord Ring，NID和KID被分配到一个大小为2^m的环上，用于资源分配（给某一个节点）和节点分布，以及资源定位（注：在这个环上的ID为0-2^m-1）。首先我们说资源分配，资源被分配到NID>=KID的节点上，这个节点成为k的后继节点，是环上从k起顺时针方向的第一个节点，记为successor(k)。而节点分布则顺时针将节点N由大到小放在这个环上。例如下边这幅图：
这是一个m=6的环，其中有10个节点，5个资源，K10的后继节点为N14，也就是说K10被分配给了N14。
2.Chord资源定位（Key Location）
资源定位是Chord协议的核心功能，为了便于理解，我们先介绍一个简单的资源定位方法，然后再介绍这个可伸缩的资源定位方法。
简单方法：
考虑如下场景：节点n寻找KID为id的资源，此时节点n首先问询是否在下一个节点上（find_successor），这要看资源k的KID是否在该节点NID和下一个节点的NID之间，若在则说明资源k被分配给了下一个节点，若不在则在下一个节点上发起同样的查询，问询下下一个点是否有该资源。如此迭代下去，用伪代码定义这个操作：
n.find_successor(id)
if (id є (n;
