BitTorrentマグネットリンクはどのように機能しますか？
初めて マグネットリンク を使用しました。それがどのように機能するのか興味があり、仕様を調べましたが、答えが見つかりませんでした。 Wikiでは、xtは「正確なトピック」を意味し、SHA1ハッシュを含む形式（この場合はbtih）が続くと述べています。 base32が言及されており、1文字あたり5ビットと32文字であることを知っており、160ビットを正確に保持することがわかりました。これは、SHA1のサイズとまったく同じです。
IPアドレスなどを入れる余地はありません。SHA1です。それでは、BitTorrentクライアントは実際のファイルをどのように見つけるのでしょうか？ URLスヌーパーをオンにして、ページにアクセスするか（TCPを使用）、ルックアップなどを行うかを確認しましたが、何も起こりませんでした。クライアントがピアを見つける方法がわかりません。これはどのように作動しますか？
また、ハッシュは何ですか？それはすべてのファイルハッシュの配列のハッシュですか？たぶん、それは必要な実際のトレントファイルのハッシュです（特定の情報を取り除く）？
VMで、uTorrent（新しくインストールした）でマグネットリンクを試したところ、ピアを見つけることができました。最初のピアはどこから来たのですか？新鮮で、他の急流はありませんでした。
BitTorrentマグネットリンクは、以下を使用してトレントを識別します1 「infohash」と呼ばれるSHA-1または切り捨てられたSHA-256ハッシュ値。これは、トラッカーまたは他のピアと通信するときにピア（クライアント）がトレントを識別するために使用する値と同じです。従来の.torrentファイルには、ダウンロードに使用するトラッカーを識別するannounceと、ファイル名とハッシュを含むinfoの2つのトップレベルキーを持つデータ構造が含まれます。急流。 「infohash」は、エンコードされたinfoデータのハッシュです。
一部のマグネットリンクには、トラッカーまたはWebシードが含まれていますが、多くの場合含まれていません。クライアントは、情報ハッシュを除いて、トレントについて何も知らない場合があります。最初に必要なのは、トレントをダウンロードしている他のピアを見つけることです。個別のピアツーピアネットワークを使用してこれを行います2 「分散ハッシュテーブル」（DHT）の操作。 DHTは、トレント（情報ハッシュで識別）を、そのトレントのスウォーム（データまたはメタデータのアップロード/ダウンロード）に参加しているピアのリスト（IPアドレスとポートで識別）にマップする大きな分散インデックスです。
クライアントがDHTネットワークに初めて参加するとき、infohashesと同じスペースからランダムな160ビットIDを生成します。次に、クライアント開発者が制御するクライアントのハードコーディングされたアドレス、または以前に急流群で遭遇したDHTサポートクライアントのいずれかを使用して、DHTネットワークへの接続をブートストラップします。特定のトレントのスウォームに参加する場合、IDが近い他のクライアントをDHTネットワークで検索します3 できるだけ情報ハッシュに。これらのクライアントにswarmに参加することを通知し、swarmに参加しているユーザーを既に知っているピアの接続情報を要求します。
ピアが特定のトレントをアップロード/ダウンロードするとき、同じトレントスウォームに参加していることを知っている他のすべてのピアについて互いに伝えようとします。これにより、トラッカーやDHTを絶えずリクエストすることなく、ピアがお互いをすばやく知ることができます。 DHTからいくつかのピアを知ると、クライアントは必要なピアがすべて揃うまで、torrent swarm内のさらに多くのピアの接続情報をそれらのピアに要求することができます。
最後に、ファイル名とハッシュリストを含むトレントのinfoメタデータをこれらのピアに要求できます。この情報をダウンロードして、既知のinfohashを使用して正しいことを確認すると、通常の.torrentファイルと含まれているトラッカーからピアのリストを取得しました。
ダウンロードが開始される場合があります。
1 通常、infohashは16進数でエンコードされますが、一部の古いクライアントはベース32を代わりに使用しました。 v1（urn:btih:）SHA-1ダイジェストを直接使用し、v2（urn:bimh:） multihash プレフィックスを追加して、ハッシュアルゴリズムとダイジェストの長さを識別します。
2 2つの主要なDHTネットワークがあります。より単純な「メインライン」DHTと、Azureusで使用されるより複雑なプロトコルです。
3 距離はXORで測定されます。
参考文献
ピアディスカバリーとリソースディスカバリー（ファイルの場合）は2つの異なるものです。
私はJXTAに精通していますが、すべてのピアツーピアネットワークは同じ基本原則に基づいています。
最初に発生する必要があるのは、ピアの発見です。
ピア検出
ほとんどのp2pネットワークは「シード」ネットワークです。最初にピアを起動すると、既知の（ハードコードされた）アドレスに接続して、実行中のピアのリストを取得します。別の投稿で言及されているdht.transmissionbt.comへの接続のような直接シード、またはピアが他のピアネットワークアドレスのプレーンテキストリストのみを配信するアドレスに接続するJXTAで通常行われる間接シードです。
最初の（数個の）ピアとの接続が確立されると、接続するピアは（要求を送信することにより）他のピアの検出を実行し、それらのテーブルを維持します。他のピアの数は膨大になる可能性があるため、接続しているピアはピアの分散ハッシュテーブル（DHT）の一部のみを維持します。接続ピアが保持するテーブルの部分を決定するアルゴリズムは、ネットワークによって異なります。 BitTorrentは、160ビットの識別子/キーでKademliaを使用します。
リソース検出
接続ピアによっていくつかのピアが検出されると、接続ピアはリソースの検出を求めるいくつかの要求を送信します。マグネットリンクはそれらのリソースを識別し、リソースの「署名」であるように構築され、すべてのピア間で要求されたコンテンツを一意に識別することを保証します。次に、接続ピアは、マグネットリンク/リソースのディスカバリリクエストを周囲のピアに送信します。 DHTは、どのピアに最初にリソースを要求するかを決定するのに役立つように構築されています（詳細については、WikipediaのKademliaを参照してください）。要求されたピアが要求されたリソースを保持していない場合、通常、自身のDHTからフェッチされた追加のピアにクエリを「渡します」。
通常、クエリを渡すことができる「ホップ」の数は制限されています。 4は、JXTAタイプのネットワークでは通常の数字です。
ピアがリソースを保持している場合、完全な詳細で応答します。接続しているピアは、リソースを保持しているピアに接続し（直接またはリレー経由-ここでは詳しく説明しません）、取得を開始します。
P2Pネットワークのリソース/サービスは、ネットワークアドレスに直接接続されているnotです。分散されているため、これらの非常にスケーラブルなネットワークの美しさです。
私も同じ質問に興味がありました。送信用のコードを読んで、libtrnasmission/tr-dht.cで次のことがわかりました。
3248: bootstrap_from_name( "dht.transmissionbt.com", 6881,
bootstrap_af(session) );
それを6回試行し、試行の間に40（！）秒待機します。構成ファイル（unixでは~/.config/transmission）を削除し、dht.transmissionbt.comへのすべての通信をブロックすることでテストでき、何が起こるかを確認できます（少なくとも240秒待ちます）。
したがって、クライアントにはbootstrapノードが組み込まれているように見えます。もちろん、一度ネットワークに接続すると、そのbootstrap =もうノード。
仕様がようやく見つかりました。初めてグーグルは助けになりませんでした 。 （メインサイトであるbittorrent.comにリンクされているウィキ。開発者リンクをクリックしました。右側のbittorrent.orgタブに注目してください。そこから簡単にアクセスできました。クリックします）。
すべてのトレントにはピアのネットワークがあるようです。トラッカーからピアを見つけ、セッション間でそれらを保持します。ネットワークを使用すると、ピアなどを見つけることができます。 magnet links でどのように使用されるかは読んでいませんが、新しいクライアントがピアを見つける方法は未定義のようです。おそらく、一部は焼き付けられているか、ホームサーバーまたはクライアントに埋め込まれた既知のトラッカーを使用して、ネットワーク内の最初のピアを取得します。
私があなたの質問に答え始めたとき、私はあなたが磁石スキームがどのように機能するかを尋ねていたことに気づきませんでした。 BitTorrentプロトコルに関連する部分がどのように生成されたかを知りたいと思っただけです。
Magnet uriにリストされているハッシュは、base32でエンコードされたトレントの情報ハッシュです。情報ハッシュは、急流のbencoded情報ブロックのsha1ハッシュです。
この pythonコード は、計算方法を示しています。
手元にベンコーダーがなく、クライアントに期待されるものと一致するため、これをテストするための（非常に単純な）C＃実装を作成しました。
static string CalculateInfoHash(string path)
{
// assumes info block is last entry in dictionary
var infokey = "e4:info";
var offset = File.ReadAllText(path).IndexOf(infokey) + infokey.Length;
byte[] fileHash = File.ReadAllBytes(path).Skip(offset).ToArray();
byte[] bytes;
using (SHA1 sha1 = SHA1.Create())
bytes = sha1.ComputeHash(fileHash, 0, fileHash.Length - 1); // need to remove last 'e' to compensate for bencoding
return String.Join("", bytes.Select(b => b.ToString("X2")));
}
私が理解しているように、このハッシュにはトラッカーを見つける方法に関する情報は含まれていません。クライアントは他の手段（提供されたアナウンスURL）でこれを見つける必要があります。これは、トラッカー上の1つのトレントを別のトレントと区別するものです。
bittorrentプロトコルに関連するすべては引き続きトラッカーを中心に展開します。それはまだ群れの間のコミュニケーションの主要な手段です。マグネットURIスキームは、BitTorrentで使用するために特別に設計されたものではありません。これは、通信の代替形式としてP2Pプロトコルで使用されます。 Bittorrentクライアントは、もう.torrentファイルをダウンロードする必要がないトレントを特定する別の方法として、マグネットリンクを受け入れるように適合しました。マグネットURIは、クライアントが参加できるように、trackerを指定して特定する必要があります。他のプロトコルに関する情報を含めることができますが、bittorrentプロトコルとは無関係です。 bittorrentプロトコルは、最終的にトラッカーなしでは機能しません。
ピアのリストは、おそらくクライアントをアップグレードするトレントから取り込まれます（たとえば、uTorrentにはそれをアップグレードするトレントがあります）。全員が同じクライアントを使用している限り、アップグレードを共有する以外に選択肢がないため、それは良いはずです。