我正在为内部集群实现自己的dht . 由于它将用于像bittorrent这样的文件共享程序，“Mainline DHT”是我第一眼看到的 . 之后我发现“纠结”（python，dht使用扭曲矩阵），国会（python，dht使用pyev libev），当然还有原始的“kademlia” .
他们在组织k-buckets时有不同的方法：
1）congress，kademlia使用固定的160个桶，范围为2 * i <=（对于我们每个id的差异）<2 *（i 1），0 <= i <160 .
2）主线DHT和纠缠使用动态桶 . 一开始他们只有一个铲斗覆盖整个空间 . 在它将填充8个活动节点后，桶将被拆分为2个新节点 . 但只有我们自己的id在那个桶里面 . 如果不是 - 桶将永远不会分裂 . 所以，很快我们将有160个最接近我们的桶和其他一些 .
两种变体都足够好 . 但是我发现逻辑上存在巨大的差异，它检测到属于某个存储桶的某个ID . 这是我的问题 .
国会和kademlia将桶子对待为"minimum distance from us"和"maximum distance from us" . 因此，我们自己的ID将始终在bucket0中 . bucket1中最多2个其他ID（因为它覆盖2 * 1 <= x <2 * 2距离）将始终最接近我们 . 所以我的大脑不会破裂，因为一切都好 .
但是，如果你看看Mainline DHT或纠缠，你会看到什么桶边框被视为绝对节点id的捆绑，而不是xor距离！所以在理论上全表id 0,1,2,3,4,5,6,7将在1个桶中 .
所以 . 为什么有些实现将桶边界视为“与我们的最大/最小距离”，而其他实现则将“最大/最小160位整数值”？
1 回答
当路由表增长时，kademlia文件实际上调用了动态拆分桶的优化 . 这两种方法之间没有逻辑差异，只是节省一些空间的优化 . 在实现固定的全尺寸路由表时，您必须找到要向其发送请求的k个节点 . 如果您的目标所在的存储桶为空，或者其中的节点少于k个，则必须从相邻存储桶中选择 . 鉴于此，让您最近的存储桶不会被拆分，使搜索更简单，更快捷 .
至于你的观点（1），我想你可能误解了kademlia . 路由表存储区边界始终与您自己的节点ID相关 . 对于远离您的每个水桶，水桶的ID空间会翻倍 . 如果没有这个属性（如果每个桶覆盖相同范围的ID空间），你将无法正确搜索，它们肯定不会是log（n） .
主线DHT实施kademlia .