1

好的，我最近一直在阅读有关 Kademlia 的文章和论文，以实现一个使用 kademlia dht 算法的简单 p2p 程序。那些论文说，Kademlia 节点中的那些 160 位密钥用于识别节点（节点 ID）和数据（以元组的形式存储）。

我对“两者”部分感到很困惑。

据我了解，Kademlia 二叉树中的每个节点都唯一地代表一个客户端（IP、端口），每个客户端都拥有一个文件列表。

这是我理解的一般流程。

  1. 客户端 (.exe) 被启动
  2. 创建节点组件
  3. 新创建的节点加入网络（引导）
  4. 将 find_node(filehash) 发送到 k-closest 节点
    • 假设哈希是通过散列名为 file1.txt 的文件二进制文件生成的
  5. 接收到的节点各自在其不同的哈希表 中找到查询的文件哈希
    • 比如说，一个包含文件列表的哈希映射（文件哈希，文件位置）
  6. 重复步骤 4,5 直到找到节点（同时所有关联节点都在更新存储桶）

这个流程看起来没问题吗？

此外，Kademlia 的引导方法也让我感到困惑。当节点被创建（用户执行程序）时，它似乎使用引导节点来填充桶。但是什么是引导节点？它是另一个一直在运行的进程吗？如果引导节点被关闭怎么办？

有人可以帮助我更好地理解这个概念吗？

我在这里先向您的帮助表示感谢。

4

1 回答 1

2

这个流程看起来没问题吗？

看起来大致正确，但是您的措辞不是很准确。

每个节点都有一个路由表，它通过它组织它知道的邻居和另一个表，它组织它被其他人要求存储的数据。节点有一个准随机 ID，用于确定它们在路由键空间中的位置。存储数据的键的散列不精确匹配任何特定的节点 ID，因此数据存储在 ID 最接近散列的节点上，由距离度量确定。这就是节点 ID 和密钥哈希用于两者的方式。

当您执行数据查找（即find_value）时，您向远程节点询问它们在其路由表中的 k-最近邻集，这将允许您找到特定目标键的 k-最近集。相同的查询还要求远程节点返回与目标 ID 匹配的任何数据。

find_node另一方面，当您执行 a时，您只要求他们提供最近的邻居而不是数据。这主要用于不查找任何数据的路由表维护。

这些是抽象操作，如果需要，实际实现可以将查找与数据检索分开，即首先执行 afind_node然后使用结果集执行一个或多个get不涉及额外邻居查找的单独操作（类似于store操作）。

由于 kademlia 是基于 UDP 的，因此您不能真正提供任意文件，因为这些文件很容易超过合理的 UDP 数据包大小。因此在实践中，kademlia 通常只用作小二进制值（例如联系信息、公钥等）的哈希表。批量操作要么由从这些值引导的其他协议执行，要么由 kademlia 论文中提到的那些之外的其他操作执行。

本文描述的只是路由算法的基本功能和最基本的键值存储。它是真空中的球形奶牛。实际实施通常需要额外的功能或解决公共互联网上面临的安全性和可靠性问题。

但是什么是引导节点？它是另一个一直在运行的进程吗？如果引导节点被关闭怎么办？

这个问题涵盖了这一点（以bittorrent DHT为例）

于 2020-01-09T19:56:50.950 回答