依赖于中央数据库来协调网络中的查询 使用泛滥式查询(query flooding)来查询文件,搜索网络中的所有节点 使用分布式散列表来查询网络中的文件

https://zh.wikipedia.org/zh-cn/Kademlia

第一代P2P文件分享网络,像Napster,依赖于中央数据库来协调网络中的查询,第二代P2P网络,像Gnutella,使用泛滥式查询(query flooding)来查询文件,它会搜索网络中的所有节点,第三代p2p网络使用分布式散列表来查询网络中的文件,分布式散列表在整个网络中储存资源的位置,这些协议追求的主要目标就是快速定位期望的节点。Kademlia基于两个节点之间的距离计算,该距离是两个网络节点ID号的异或( XOR distance ),计算的结果最终作为整型数值返回。关键字和节点ID有同样的格式和长度,因此,可以使用同样的方法计算关键字和节点ID之间的距离。节点ID一般是一个大的随机数,选择该数的时候所追求的一个目标就是它的唯一性(希望在整个网络中该节点ID是唯一的)。异或距离跟实际上的地理位置没有任何关系,只与ID相关。因此很可能来自德国澳大利亚的节点由于选择了相似的随机ID而成为邻居。选择异或是因为通过它计算的距离享有几何距离公式的一些特征,尤其体现在以下几点:节点和它本身之间的异或距离是0;异或距离是对称的:即从A到B的异或距离与从B到A的异或距离是等同的;异或距离符合三角不等式:三个顶点A B C,AC异或距离小于或等于AB异或距离和BC异或距离之和。由于以上的这些属性,在实际的节点距离的度量过程中计算量将大大降低。Kademlia搜索的每一次迭代将距目标至少更近1 bit。一个基本的具有2的n次方个节点的Kademlia网络在最坏的情况下只需花n步就可找到被搜索的节点或值。

 

Kademlia协议共有四种消息。

  • PING消息—用来测试节点是否仍然在线。
  • STORE消息—在某个节点中存储一个键值对
  • FIND_NODE消息—消息请求的接收者将返回自己桶中离请求键值最近的K个节点。
  • FIND_VALUE消息,与FIND_NODE一样,不过当请求的接收者存有请求者所请求的键的时候,它将返回相应键的值。每一个RPC消息中都包含一个发起者加入的随机值,这一点确保响应消息在收到的时候能够与前面发送的请求消息匹配。

 

在文件分享网络中的应用

Kademlia可在文件分享网络中使用,通过制作Kademlia关键字搜索,我们能够在文件分享网络中找到我们需要的文件以供我们下载。由于没有中央服务器存储文件的索引,这部分工作就被平均地分配到所有的客户端中去:假如一个节点希望分享某个文件,它先根据文件的内容来处理该文件,通过运算,把文件的内容散列成一组数字,该数字在文件分享网络中可被用来标识文件。这组散列数字必须和节点ID有同样的长度,然后,该节点便在网络中搜索ID值与文件的散列值相近的节点,并把它自己的IP地址存储在那些搜索到的节点上,也就是说,它把自己作为文件的源进行了发布。正在进行文件搜索的客户端将使用Kademlia协议来寻找网络上ID值与希望寻找的文件的散列值最近的那个节点,然后获取存储在那个节点上的文件源列表。

由于一个键可以对应很多值,即同一个文件可以有多个源,每一个存储源列表的节点可能有不同的文件的源的信息,这样的话,源列表可以从与键值相近的K个节点获得。 文件的散列值通常可以从其他的一些特别的Internet链接的地方获得,或者被包含在从其他某处获得的索引文件中。

文件名的搜索可以使用关键词来实现,文件名可以分割成连续的几个关键词,这些关键词都可以散列并且可以和相应的文件名和文件散列储存在网络中。搜索者可以使用其中的某个关键词,联系ID值与关键词散列最近的那个节点,获取包含该关键词的文件列表。由于在文件列表中的文件都有相关的散列值,通过该散列值就可利用上述通常取文件的方法获得要搜索的文件。

 

posted @ 2026-04-16 22:07  papering  阅读(8)  评论(0)    收藏  举报