我正在阅读Kademlia white paper 并尝试实现路由表部分。
我使用的是 160 位地址空间，并且有一个包含 160 k 桶的数组。据我了解，此实现将通过节点 ID 具有多少前导零位将节点 ID 存储在存储桶中。 IE。 bucket[0] 的节点 ID 有 160 个前导零（只有 1 个节点），bucket[159] 的节点没有前导零（占整个地址空间的 50%）。
问题 使用这种实现，当找到最接近目标 nodeId 的 k 节点时，我是否会只计算目标的前导零并返回该 k 桶中的所有内容？
使用这个实现，我看不到任何地方/不需要使用 Kademlia 构建的 XOR，所以我认为我的实现不正确。
【问题讨论】：
首先提醒一下：您链接到的论文是the pre-proceedings version only containing the basic sketch without later refinements。 160 桶阵列路由表布局是论文证明的简化方法，后来的修订引入了更复杂的基于树的表。
即bucket[0] 的节点 ID 有 160 个前导零（只有 1 个节点），而 bucket[159] 的节点没有前导零（占整个地址空间的 50%）。
嗯，你可以这样做，但只计算异或距离中的前导零并将其用作索引更简单。 IE。 0 个共享前缀位 = 无 (0) 个前导零 = buckets[0] = 距离您自己的 ID 最远的存储桶。
问题使用这个实现，当找到最接近目标 nodeId 的 k-nodes 时，我是否会只计算目标的前导零并返回该 k-bucket 中的所有内容？
以下假设您正在询问如何回答远程节点的查询。
平面路由表布局中的存储桶是根据您自己的节点 ID 组织的。在回答对某个任意目标 ID 的查询时，这不一定与该目标的接近程度一致。因此，最简单的方法是扫描路由表中所有填充的存储桶，并计算与查询目标地址相关的 N 个最近节点，然后将它们作为响应返回。避免完全扫描会涉及到一些arithmetic on the xor metric to find the correct local buckets，但我只为基于树的布局而不是平面布局这样做。
【讨论】：