高度不平衡的 Kademlia 路由表

Posted 2023-04-15

【中文标题】高度不平衡的 Kademlia 路由表

【英文标题】：Highly unbalanced Kademlia routing table

【发布时间】：2015-11-14 18:54:56

【问题描述】：

在 Kademlia 论文中，第 2.4 节的最后一段指出，为了正确处理高度不平衡的树...

Kademlia 节点将所有有效联系人保存在大小至少为 k 的子树中 节点，即使这需要拆分节点自己的存储桶 ID 不存在。

但是，论文的前一部分似乎指出，如果 k-bucket 已经有 k 个元素，则对该 k-bucket 的任何进一步添加都需要删除最旧的节点（首先对其进行 ping 操作以查看其是否存在）或以其他方式缓存添加，直到该 k-bucket 中的插槽可用。

这篇论文似乎与这两点自相矛盾。

在什么条件下应该拆分 k-bucket，为什么？在路由表中保留“所有有效联系人”似乎不切实际，因为路由表会很快变得非常大。该示例讨论了一棵树，它有许多以 001 开头的节点和一个以 000 开头的节点。以 000 开头的节点必须不断地将其 k-bucket 拆分为 001 以容纳每个以 001 开头的有效节点？在 160 位的地址空间中，那最终不会在 000 的路由表中存储 2^157 个节点吗？？

引用块中的措辞也很混乱……

"in a subtree" -- 在路由表的哪个子树中？

“大小至少 k 个节点”——我们使用什么度量来确定子树的大小？在这种情况下，节点是指 kademlia 节点或 k-buckets 或其他什么？

【参考方案1】：

但是，论文的前一部分似乎指出，如果 k-bucket 已经有 k 个元素，则对该 k-bucket 的任何进一步添加都需要删除最旧的节点（首先对其进行 ping 操作以查看其是否存在）或以其他方式缓存添加，直到该 k-bucket 中的插槽可用。

这就是当有节点联系人要插入但桶不符合拆分条件时维护桶的方式。

在什么情况下应该拆分k-bucket，为什么要拆分？

作为第一个近似值：当无法插入新节点时拆分存储桶并且存储桶的 ID 空间覆盖您的节点 ID。

这对于保持对您的邻居的全面了解而对远程键空间部分只有模糊的了解是必要的。 IE。地点。

为了涵盖不平衡树的情况——如果节点 ID 不是（伪）随机的，或者至少在叶桶中，由于随机分配时的统计侥幸，这种情况可能会发生——这种方法必须是放宽如下：

什么时候

正在尝试在路由表中插入新联系人C C所属的桶已满 C 比您的路由表中的 K^th-最近的节点更接近您的节点 ID，其中 K 是桶大小

然后拆分桶。

在实践中，这必须进一步修改，以便对响应使​​用宽松拆分，而未经请求的请求应该只使用严格拆分，否则当表在启动期间早期发生宽松拆分时，您可能会得到一些奇怪扭曲的路由表尚未填充。

【讨论】：

感谢您的回答。在过去的一周里，我一直在努力理解这一点。您在此处概述的内容与原始论文中的内容一致吗？

难题。我想说这是一种实现方法，相当于论文中各个段落的意图。几个月前，实际上有人在 IRC 上提出了这部分内容，我不得不考虑很长时间，直到我真正得到它。我之前对 Kademlia 的推理是错误的，所以我不愿意断言我的解释是正确的。也就是说，现实世界的实现通常远不那么精确（仅实现第一个近似值），只要 ID 是均匀分布的，它似乎仍然有效。它只会让它们更吵。

我也在为原始论文而苦苦挣扎。它似乎自相矛盾。在一个部分中，它讨论了 160 个基于距离的 k 个桶，在另一个部分中，它讨论了一个基于密钥的 k 个桶的二叉树，其大小是动态的。网络上有什么东西可以把它翻译成简单的英语吗？

算法如何枚举最接近某个目标 ID T 的一组 N 节点与此答案无关。但是，是的，我在另一个答案中概述了这样的算法。在这种特殊情况下，它是 T = 您自己的节点 ID。

@masterwok irc 频道将在 freenode 上为 ##bittorrent。