Kademliaの最も近い良いノードiは、ハッシュID与えられた最も近い良いノードを見つけるために定義されたKademliaのアルゴリズムを使用し、bep44の実装に取り​​組んで2つの要求

Question

の間で十分と交差しています。

私のプログラムを使用して、私はgo run main.go -put "Hello World!" -kname mykey -salt foobar2 -b publicを実行し、100ノード以上（良い）に格納された値を取得します。

今、私はそれを複数回連続して実行すると、put要求によって書き込まれたIPのセットがうまく交差しません。

getリクエストを実行しようとすると、照会されたipsのセットがプットセットと交差しないため、値が見つからないような問題があります。

私は通常後〜1Kのクエリのリストで終わる公共のDHTブートストラップノード

 "router.utorrent.com:6881", 
     "router.bittorrent.com:6881", 
     "dht.transmissionbt.com:6881", 

私は、ノードを照会するとき、私は8つの、最も近いノード（nodes := s.ClosestGoodNodes(8, msg.InfoHash())）を選択し、使用して私のテストで

再帰的トラバーサル。私の理解で

は、DHTテーブルの情報ハッシュのアドレスを格納するテーブルの状況与えられた決定論的です。私は連続したクエリを行っているので、私はテーブルが実際には変わると思っていますが、それほど多くはありません。

どのように店のノードセットが交差していないが起こるのでしょうか？

Answer 1

BEP44は、DHTノードのサブセットでのみサポートされているため、最も近いノードのセットが安定しているかどうかを判断し、ルックアップを終了できるかどうかを判断する際に反復ルックアップのメカニズムを考慮する必要があります。

ノードがGET応答の中でtoken、vまたはseqフィールドを返した場合、それは最も近い設定の読み取り専用はを取得のための資格です。

ノードがtokenを返した場合、それは最も近い設定のための資格です操作を置くが続くことを取得します。

したがって、ターゲットIDに最も近いが問題の操作に適さないキースペース内のノードのセットが検索される可能性があります。あなたが最もよく知られている適格な連絡先よりも近い候補者を持っている限り、検索を続行する必要があります。ターゲット周りの探索領域を概念的に広げているので、この周長を広げています。

また、putリクエストを実行するときに、エラー応答または応答がないことも考慮する必要があります。ノードを再試行するか、代わりに適格ノードを試すことができます。

additional constraints私は、独自のDHT実装のドキュメントで、堅牢性とセキュリティ上の理由から、最も近いセットをルックアップに入れたいと思っていると書いています。

通常、再帰的トラバーサル後に〜1Kクエリのリストになります。

これは、ルックアップアルゴリズムに問題があることを示しています。私の経験では、検索は並行リクエストで検索している場合はターゲットを見つけるのに60から200の間のudpリクエストの間しか取れません。

Verbose logs眼球にはどのようにルックアップが進行し、どのくらいの迷惑メールが私に届きましたか？私はあなたがディスクにあなたのルーティングテーブルを作成し、そこだけからそれをリロードする必要があり、公共のDHTブートストラップノード

を使用し、私のテストでは

あなたのRTに固執したノードのどれもが到達しないときにブートストラップを実行します。それ以外の場合は、ブートストラップノードのリソースを無駄にしてしまい、ルックアップを実行する前にルーティングテーブルを最初に再設定しなければならないため、時間を浪費します。