DHT:BitTorrent vs kademlia vs clones（python）

Question

我正在为内部集群实现我自己的dht。因为它将用于像bittorrent这样的文件共享程序，“主线DHT”是我首先要看的东西。之后我发现了“纠缠”（python，dht使用twisted matrix）、congress（python，dht使用pyev+libev），当然还有原始的“kademlia”。在

他们有不同的方法来组织k-bucket：

1）国会，kademlia在2*i<；=（美国每个id的差异）<；2*（i+1）范围内使用固定的160桶，0<；=i<；160。在

2）主线DHT和缠绕使用动态铲斗。一开始他们只有一个桶覆盖整个空间。当它充满8个活动节点后，bucket将被拆分为2个新节点。但前提是我们自己的身份证在桶里。如果不是的话——桶永远不会被分开。所以，很快我们将有160个最接近我们的水桶和其他几个。在

两种变体都足够好。但是我发现在逻辑上有很大的不同，检测是否属于某个桶的某个id。这是我的问题。在

国会和卡德姆利亚将桶型联邦政府视为“与我们的最小距离”和“与我们的最大距离”。所以，我们自己的身份证永远在bucket0里。bucket1中最多有2个其他id（因为它覆盖了2*1<；=x<；2*2的距离）总是离我们最近。所以我的大脑不会坏，因为一切都好。在

但如果你看看主线DHT或纠缠，你会看到什么桶bundaries处理为绝对节点id bundaries，而不是异或距离！所以在理论上，完整的表id 0,1,2,3,4,5,6,7将在1个bucket中。在

所以。为什么有些实现将存储桶边界视为“与我们的最大/最小距离”，而另一些则将其视为“最大/最小160位整数值”？？在

Answer 1

kademlia的论文实际上提出了随着路由表的增长动态拆分bucket的优化。这两种方法在逻辑上没有区别，只是为了节省一些空间而进行的优化。当实现固定的全尺寸路由表时，您必须找到k个节点来发送请求。如果你的目标所在的bucket是空的，或者少于k个节点，你必须从相邻的bucket中选择。鉴于此，首先不要分割离你最近的存储桶，这会使搜索更简单、更快。在

至于你的第（1）点，我想你可能误解了卡德姆里亚。路由表的bucket边界总是相对于您自己的节点ID，并且对于距离您更远的每个bucket，bucket的ID空间跨越两倍。如果没有这个属性（假设每个bucket覆盖了相同的ID空间范围），您将无法正确地进行搜索，而且它们肯定不会是log（n）。在

干线DHT实现kademlia。在