1

私はさらに別のビットトレント クライアントの実装に取り​​組んでおり、現時点では DHT に苦労しています。この仕様http://www.bittorrent.org/beps/bep_0005.htmlに従って実装されていますが、デバッグを開始すると、ネットワーク上の他のノードの応答が異なることに気付きました。

たとえば、find_node は、ターゲット ノード情報または 8 つの最も近いノードのいずれかを返すことになっています。ほとんどのノードは 34 の最も近いノードで応答し、通常、それら 34 のうち 1 ～ 3 つのノードのみが結果の ping 要求に正常に応答します。

より良い実装の推奨事項を記載した別のドキュメントはありますか? ノードの状態を疑わしい状態に変更するために 15 分間隔を使用することは効率的ではないことが既に証明されている可能性があり、10 または他の数値を使用する必要がありますか? 最新の最適な提案はどこで見つけることができますか?

もう一つ奇妙なことがあります。router.bittorrent.com のようなブートストラップ ノードは、さらに最も近いノードで応答し、通常、「ノード」BDictionary プロパティのバッファー長は 6 で割り切れません (コンパクトなノード情報: IP の場合は 4、ポートの場合は 2)。今のところ、6 で割り切れる最も近い長さでバッファーを切り取るだけですが、それはすべて奇妙です。なぜそれが起こるのか誰か知っていますか？

4

1 に答える 1

2

仕様には次のように書かれています（強調は私のものです）：

ノードが find_node クエリを受信すると、キー「nodes」と[...]のコンパクト ノード情報を含む文字列の値で応答する必要があります。

さらに下：

ノードの連絡先情報は、 26 バイトの文字列としてエンコードされます。「コンパクト ノード情報」とも呼ばれ、ネットワーク バイト オーダーの 20 バイトのノード ID には、最後に連結されたコンパクトな IP アドレス/ポート情報があります。

さらに、ビットトレント BEP はそこで説明されている概念に基づいて構築されており、それらの概念の詳細な説明が省略されているため、元の Kademlia の論文を読む必要があります。

現在、ほとんどの実装で多かれ少なかれ事実上の標準になっているいくつかの拡張機能についてもお読みください。 http://libtorrent.org/dht_extensions.html

また、他の DHT 関連のBEPを読んでください。一部はかなり広く採用されており、BEP-5 で指定された動作を変更/明確化していますが、一般的には下位互換性のある方法です。

たとえば、find_node は、ターゲット ノード情報または 8 つの最も近いノードのいずれかを返すことになっています。

ノードは可変量のエントリを返します。8 より多いか、それより少ない可能性があります。

于 2015-07-09T09:22:06.153 に答える