内部クラスター用に独自の dht を実装中です。bittorrent のようなファイル共有プログラムで使用されるため、最初に見たのは「Mainline DHT」でした。その後、「絡み合った」（python、ツイストマトリックスを使用したdht）、議会（python、pyev + libevを使用したdht）、そしてもちろんオリジナルの「kademlia」を見つけました。
k-bucket を整理するためのさまざまなアプローチがあります。
1) 議会、kademlia は、0 <= i < 160 の場合、2* i <= (各 ID の差) < 2 *(i+1) の範囲で固定の 160 バケットを使用します。
2) メインラインの DHT と entangled はダイナミック バケットを使用します。最初は、スペース全体をカバーするバケツが 1 つしかありません。8 つの生きているノードでいっぱいになると、バケットは 2 つの新しいノードに分割されます。ただし、そのバケット内に独自の ID がある場合のみ。そうでない場合 -- バケットは決して分割されません。そのため、すぐに 160 個の最も近いバケットとその他のバケットがいくつかあります。
どちらのバリアントでも十分です。しかし、IDがバケットに属しているかどうかを検出するロジックに大きな違いがあることがわかりました。これが私の質問です。
congress と kademlia は、バケット境界線を「私たちからの最小距離」および「私たちからの最大距離」として扱います。したがって、私たち自身の ID は常にbucket0 にあります。バケット 1 の最大 2 つの他の ID (2* 1 <= x < 2 *2 の距離をカバーするため) は、常に私たちに最も近いものになります。だから私の脳は壊れません。
しかし、Mainline DHT または entangled を調べると、xor 距離ではなく、絶対ノード ID 境界として扱われるバケット境界が表示されます。したがって、理論的に完全なテーブル ID では、0、1、2、3、4、5、6、7 が 1 つのバケットになります。
そう。一部の実装では、バケット境界を「私たちからの最大/最小距離」として扱い、他の実装では「最大/最小 160 ビット整数値」として扱うのはなぜですか??