如何将Kademlia路由表表示为数据结构

Question

kademlia paper讨论了存储桶的组织，拆分，合并和查找要插入抽象，concise和confusing术语的正确存储桶。

§2.2讨论了一组固定的160个存储桶，每个存储桶覆盖了键空间的固定子集。但是后面的章节涉及覆盖键空间不同部分的其他拆分和存储桶。不太适合固定列表

组织存储桶的正确方法是什么？

_{元：由于混乱反映在许多问题中，部分信息分散在许多答案中，因此本问答旨在提供易于链接的说明}

Answer 1

混乱源于from different versions of the paper。

平面布局

这是预印本，主要用于从理论上概述卡德姆利亚的基本特性，但仍反映在完整版的第2.2和§3中。

许多现实世界中的实现都实现了这种方法，但是它们没有实现存储桶拆分，合并或node multihoming。

这涉及将联系人放入与节点共享i前缀位的第i个存储桶中。这意味着布局使用相对于节点自己的ID的距离。

基于树的布局

这在§2.4部分中进行了描述。

要实现改进，例如处理在{em>§2.4末尾描述的highly unbalanced trees或在§4.2中描述的更深层的非本地拆分，则需要将每个关联存储桶，其中包含其覆盖的键空间范围this can be expressed similar to CIDR ranges，即起始ID和为掩盖ID的尾部而共享的前缀位数。

通过将前缀位的数量增加1并将两个新存储区的添加位分别设置为0和1，来进行存储区的拆分。

与平面布局不同，此结构不涉及相对于节点自己的ID的距离，尽管某些决定是基于节点自己的ID是否会落入桶中。

由于此类路由表中存储区的数量随时间的变化而有所变化，因此必须在可调整大小的数据结构中表示，因此在§2.4中进行了提及。由于无法再通过固定索引进行访问，因为直到检查了前缀范围之后，才能知道覆盖任何特定节点ID的确切存储桶，如果要避免，则需要某种O(log n)搜索每次都扫描整个存储桶列表。
按照存储桶将要覆盖的最低ID对存储桶进行排序是一种很自然的方法。 BTree或排序数组结合二进制搜索可用于实现此目的。

无论采用哪种方法，都必须使用与请求目标is not trivial相匹配的正确联系人集合来填充对find_node请求的响应，因为任何单个存储桶可能都不足以填充它，因此需要多个存储桶被遍历。扫描整个路由表以寻找最佳可用候选者可能更简单。

Answer 2

经过一些在线研究并重新阅读了几次论文，我认为我明白了。在第2部分（系统说明）某处文件的最终版本中说：

  

本节的其余部分将填充详细信息并使查询算法更加具体。我们首先定义一个精确的ID紧密度概念，使我们可以说是在与密钥最接近的k个节点上存储和查找对。然后，我们提供了一种查找协议，即使在没有节点使用键共享唯一前缀或与给定节点关联的某些子树为空的情况下，该协议仍然有效

定义“ ID紧密度的精确概念”的部分在2.1小节中完成。因此，这在2.2和2.3小节中“允许”我们说“在与密钥最接近的k个节点上存储和查找对”，我们将了解查找过程的工作原理。现在，第2.4节将解决在没有节点使用密钥共享唯一前缀（又称不平衡树）的情况下进行查找的问题，这是实际完成的“查找协议”。

因此，数组结构在开始时就用作虚拟结构，我们用来了解查找过程，在了解了查找过程的工作原理之后，我们将其引入到更高级的树结构中。
这就是作者可能想到的。