問題タブ [kademlia]

私はツイストを使用して P2P アプリケーションに取り組んでいます。DHT で特定のキーを繰り返し検索し、値が変更されるたびに辞書に追加しようとしています。コードは、達成したいことを多かれ少なかれ実行していますが、新しい値を取得すると、まだ複数のリクエストが実行されています。これにより、最大再帰深度を超えたことを示す実行時エラーが発生することがあります。これを変更して、一度に 1 つの get リクエストのみを実行するようにするにはどうすればよいですか? 私はツイストを使用したことがないので、まだコツをつかもうとしています。

Kademlia は XOR メトリックを使用します。とりわけ、これにはいわゆる「単方向」特性があります (= 任意の点 x と距離 e>0 に対して、d(x,y)=e となる点 y が 1 つだけ存在します)。

最初の質問は一般的な質問です。メトリックのこのプロパティは Kademlia の機能にとって重要ですか、それとも特定のノードからの圧力を明らかにするのに役立つだけのものですか (元の論文が示唆しているように)。言い換えれば、メトリックを変更したい場合、「一方向」のメトリックも付属することがどれほど重要なのでしょうか?

2 番目の質問は、メトリックの具体的な変更に関するものです。ノード識別子 (アドレス) が X ビットの数値であると仮定すると、次のメトリックのいずれかが Kademlia で機能しますか?

1. d(x,y) = abs(x-y)
2. d(x,y) = abs(x-y) + 1/(x xor y)

最初のメトリックは単に数値の差を提供するため、ノード ID 100 の場合、ID 90 と 110 のノードは同じ距離にあるため、これは単方向のメトリックではありません。2 番目のケースでは、1/(x xor y) を追加することを修正します。ここで、(x xor y) は単方向であることがわかっているため、1/(x xor y) を使用するとこのプロパティが保持されます。

したがって、ノード ID 100 の場合、ノード ID 90 はd(100,90) = 10 + 1/62であり、ノード ID 110 からの距離は ですd(100,110) = 10 + 1/10。

これは私をひどく困惑させました。

元の Kademlia では、sha1 のような 160 ビットの 16 進数を使用する必要があることが明らかな理由で提供されています。infohash に関連するピアを検索するときは、sha1 infohash と同じシステムと同等である必要があるため、nodeID を検索するだけです。

しかし、これを読む: http://www.bittorrent.org/beps/bep_0005.html

ID は次のabcdefghi0123456789とおりです。1) 半分のサイズ 2) 標準の 16 進エンコーディングよりも多くの文字を使用します。

それで、私は何が欠けていますか？

なぜノード ID はこのようになっているのですか?

私は2つのJavaライブラリを持っています。1 つは DHT に接続し、torrent ファイルを正常にダウンロードできます。もう 1 つは、トレントに関連付けられた実際のデータをダウンロードします。

トレント クライアント ライブラリは、トレント内のアナウンスまたはアナウンス リスト セクションを想定しており、「ノード」エントリを認識しません。

問題は、トレント ファイルの「ノード」セクションを理解するために、トレント クライアント コードを変更する方法です。または、一連の ip:port DHT ピア アドレスからトラッカー URL を計算するにはどうすればよいですか?

ポート番号を推測して /announce を追加することで URL を推測することもできますが、これは正しくありませんか?

これがどのように機能するか知っている人はいますか？

ノードが Kademlia ネットワークに参加したい場合、ブートストラップ プロセスの一部としてブートストラップ ノードを検索します。実際、このJava 実装は同じように見えます。

ビットコイン プロトコルでも、ノードは他のピア ノードが誰であるかを知るために検索します。また、優先モードは DNS シードのようです。この回答から引用すると、

現在、Bitcoin Core クライアントや他の多くの実装は、DNS シードに依存しています。DNS シードは、ネットワークからランダムに選択された多数のノードを返すように構成された特別な DNS サーバーです。DNS シードのオペレーターは、クローラーも実行して、シードによって返される公に到達可能なノードを列挙します。

そのような検索メカニズムは Kademlia ノードに存在しますか?

bep44 の実装に取り​​組んでいます。定義済みの kademlia アルゴリズムを使用して、与えられたハッシュ ID に最も近い適切なノードを見つけます。

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

ここで、複数回連続して実行すると、put リクエストによって書き込まれた ip のセットがうまく交差しません。

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

私のテストでは、パブリック dht ブートストラップ ノードを使用します。

ノードにクエリを実行するとき、最も近い 8 つのノード ( nodes := s.ClosestGoodNodes(8, msg.InfoHash())) を選択します。これは通常、再帰的なトラバーサルの後、約 1K のクエリのリストになります。

私の理解では、情報ハッシュのアドレスを dht テーブルに格納することは、テーブルのステータスを考えると決定論的です。連続したクエリを実行しているため、テーブルが実際に変更されることを期待していますが、それほどではありません。

ストア ノード セットが交差しないのはなぜですか?

ターゲット ID x...19x が与えられた場合、プログラムが再帰クエリを実行し、テーブルを構築し、調査するノードがなくなると、最も近い結果のノードが 8 未満である状況を見つけると考えてみましょう。

テーブルが特定の id に対して少なくとも 8 つのノードを返すように検索を広げるにはどうすればよいですか?

単純にターゲット ID (情報ハッシュ) を取得して、 info_hash+1 / info_hash-1 を検索できますか?

もしそうなら、プログラミング用語では、このフォーム "afe0..." で指定された ID を増減する方法は?

そうでない場合、その数の冗長ノードに到達するにはどうすればよいでしょうか?