私は Kademlia について読み、その基本的な概念を理解しました。BitTorrent の基本的な概念も簡単に理解できます。しかし、両方を一緒にするとまったく意味がなくなります。
私がオンラインで見つけたものによると、ターゲット ファイルのファイル ハッシュは、DHT で検索するターゲット ID を生成するために使用され、その検索によってターゲット ID に近いピアが検索されるはずです。なるほど、理にかなっています。ただし、まったく理にかなっていません。ターゲット ID に近い ID を持つピアが、ネットワーク上のシーダーや他のピアについて何かを知るのはなぜでしょうか。
関連性を調査しようとする試みはすべて、DHT アルゴリズムが Kademlianess を使用して、ピア ID がターゲット ID に近いピアに到達するという同じ説明に終わりましたが、これでは質問に対する答えにはなりません。
答え1
私の理解では、「ターゲットIDを持つピア」はシーダーや他のピアについて知っている。なぜなら、それらのピアもまったく同じ手順を使用して店その場所に自分自身に関する情報が保存されます。その ID を持つピアは、他のすべてのピアが同意して、何かに関連するデータを保存/取得する場所です。
DHTは「分散ハッシュテーブル」であり、「ハッシュ表「ハッシュテーブル」とは、{キー⇒値}のマッピングを格納するデータ構造（辞書、連想配列、ルックアップテーブルなどとも呼ばれる）を意味します。ハッシュテーブルを使用するプログラムは、put(キー、値)そしてハッシュテーブルは{キー⇒値}情報をアドレスXに格納します。その後、プログラムの別の部分で取得(キー)ハッシュテーブルはアドレス X から値を取得します。
一般的なハッシュテーブルがプログラム内で使用される場合、ハッシュテーブルは、特定の検索キー (ハッシュ) が保存されるときに同様の手順を使用してメモリ位置を生成し、取得する必要があるときにも同じことを行います。データベース、ファイルシステム、Git なども、さまざまなレベルで同じことを行います (例: Git の .git/objects/)。
DHT はネットワーク レベル (「分散」部分) のみで同じです。BitTorrent の DHT は BT 固有の機能をいくつか認識しますが、基本的には BitTorrent クライアントが合意した場所に保存する必要があるデータを保存するだけです。Kad 仕様では次のように述べられています。
<キー、値> ペアを保存するには、参加者は... を見つけます。
つまり、一般的に言えば、次のようなファイル共有プロトコルに統合できます。
ソース ノード S (ファイルを持つ) は ID を計算し、DHT ネットワーク経由で「保存」操作を送信して、情報 {キー: fileID ⇒ 値: "ノード S で使用可能"} を保存します。この情報は、キー (fileID) に最も近いノード X に送信されます。
情報 {キー: fileID ⇒ 値: "ノード S で利用可能"} はノード X に保存されます。
別のピア/クライアント ノード C はファイルの ID を学習し、DHT ネットワーク経由で「取得」操作を送信します。これにより、ノード X から「ノード S で使用可能」な値が取得されます。
のビットトレントDHTこの例と同様の方法で実装されますが、「保存」操作のみが呼び出されannounce_peer、値を完全に上書きするのではなく、アナウンサーのデータを既に保存されているピアのリストに追加するだけです。