BitTorrentマグネットリンクはどのように機能しますか？

初めてマグネットリンクを使用しました。それがどのように機能するのか知りたくて、仕様を調べましたが、答えは見つかりませんでした。wikiはxt「正確なトピック」を意味btihし、SHA1ハッシュの形式（この場合）が続きます。1文字あたり5ビット、32文字であることを知っているbase32について言及したところ、SHA1のサイズとまったく同じ160ビットを保持していることがわかりました。

IPアドレスなどを入れる余地はなく、単なるSHA1です。では、BitTorrentクライアントはどのようにして実際のファイルを見つけるのでしょうか？URLスヌーパーをオンにして、（TCPを使用して）ページにアクセスしたか、ルックアップなどを行ったかを確認しましたが、何も起こりませんでした。クライアントがどのようにして仲間を見つけるのか私にはわかりません。これはどのように作動しますか？

また、ハッシュは何ですか？すべてのファイルハッシュをまとめた配列のハッシュですか？多分それは必要な実際の急流ファイルのハッシュ（特定の情報を取り除いたもの）でしょうか？

VMで、（新しくインストールされた）uTorrentとのマグネットリンクを試しましたが、ピアを見つけることができました。最初のピアはどこから来たのですか？それは新鮮で他の急流はありませんでした。

A BitTorrentの磁石リンク識別使用トレント¹ "infohash"として知られているSHA-1又は切り捨てSHA-256ハッシュ値を。これは、トラッカーまたは他のピアと通信するときにピア（クライアント）がトレントを識別するために使用するのと同じ値です。従来の.torrentファイルにはannounce、ダウンロードに使用するトラッカーを識別する2つの最上位キーを持つデータ構造とinfo、トレントのファイル名とハッシュを含むデータ構造が含まれています。「infohash」は、エンコードされたinfoデータのハッシュです。

一部のマグネットリンクには、トラッカーまたはWebシードが含まれていますが、含まれていないことがよくあります。あなたのクライアントは、その情報ハッシュを除いて、急流について何も知らないかもしれません。最初に必要なのは、急流をダウンロードしている他の仲間を見つけることです。これは、「分散ハッシュテーブル」（DHT）を操作する個別のピアツーピアネットワーク^2を使用して行われます。DHTは、トレント（情報ハッシュによって識別される）を、そのトレント（データまたはメタデータのアップロード/ダウンロード）のスウォームに参加しているピア（IPアドレスおよびポートによって識別される）のリストにマップする大きな分散インデックスです。

クライアントが初めてDHTネットワークに参加するとき、infohashと同じスペースからランダムな160ビットIDを生成します。次に、クライアント開発者によって制御されたクライアントのハードコードされたアドレス、または以前に急流群で遭遇したDHT対応クライアントを使用して、DHTネットワークへの接続をブートストラップします。それは与えられた急流のために群れに参加したい場合は、IDの近くにあるいくつかの他のクライアントのためのDHTネットワークを検索し³ infohashにできるだけを。スウォームに参加することをこれらのクライアントに通知し、スウォームに参加しているユーザーがすでに知っているピアの接続情報をクライアントに要求します。

ピアが特定のtorrentをアップロード/ダウンロードするとき、同じtorrent群に参加していることを知っている他のすべてのピアについてお互いに伝えようとします。これにより、トラッカーやDHTに一定のリクエストを行うことなく、ピアがお互いをすばやく知ることができます。DHTからいくつかのピアを学習すると、クライアントは、必要なピアがすべて揃うまで、トレントスウォーム内のさらに多くのピアの接続情報をそれらのピアに要求することができます。

最後に、infoファイル名とハッシュリストを含むトレントのメタデータをこれらのピアに要求できます。この情報をダウンロードし、既知のを使用してそれが正しいことを確認したらinfohash、通常の.torrentファイルから始めて、含まれているトラッカーからピアのリストを取得したクライアントと実質的に同じ位置にいます。

ダウンロードが始まる場合があります。

_{¹ infohashは通常16進エンコードされていますが、一部の古いクライアントは代わりにbase 32を使用していました。v1（urn:btih:）はSHA-1ダイジェストを直接使用しますが、v2（urn:bimh:）はマルチハッシュプレフィックスを追加して、ハッシュアルゴリズムとダイジェストの長さを識別します。
^{2 2}つの主要なDHTネットワークがあります。より単純な「メインライン」DHTと、Azureusで使用されるより複雑なプロトコルです。
³距離はXORで測定されます。}

参考文献

• BEP-3：BitTorrentプロトコル仕様
• BEP-52：BitTorrentプロトコル仕様v2
• BEP-5：DHTプロトコル
• BEP-9：ピアがメタデータファイルを送信するための拡張機能
• BEP-10：拡張プロトコル
• BEP-11：ピア交換（PEX）
• Azureus DHTの説明

ピアディスカバリとリソースディスカバリ（ここではファイル）は2つの異なるものです。

私はJXTAに慣れていますが、すべてのピアツーピアネットワークは同じ基本原理で動作します。

最初に発生する必要があるのは、ピアの発見です。

ピアディスカバリー

ほとんどのp2pネットワークは「シード」ネットワークです。最初にピアを起動すると、既知の（ハードコードされた）アドレスに接続して、実行中のピアのリストを取得します。dht.transmissionbt.com他の投稿で述べられているように接続するような直接シード、 または他のピアネットワークアドレスのプレーンテキストリストのみを配信するアドレスにピアが接続するJXTAで通常行われる間接シードにすることができます。

最初の（少数の）ピアとの接続が確立されると、接続ピアは（要求を送信することにより）他のピアの検出を実行し、それらのテーブルを維持します。他のピアの数は膨大になる可能性があるため、接続するピアは、ピアの分散ハッシュテーブル（DHT）の一部のみを維持します。接続ピアが維持する必要があるテーブルの部分を決定するアルゴリズムは、ネットワークによって異なります。BitTorrentは、160ビットの識別子/キーを持つKademliaを使用します。

リソースの発見

接続するピアによっていくつかのピアが検出されると、接続するピアはリソースの検出のためにいくつかの要求を送信します。マグネットリンクはそれらのリソースを識別し、それらがリソースの「署名」であるように構築され、すべてのピア間で要求されたコンテンツを一意に識別することを保証します。接続ピアは、マグネットリンク/リソースのディスカバリリクエストを周囲のピアに送信します。DHTは、どのピアにリソースを最初に要求するかを決定するのに役立つように構築されています（詳細については、WikipediaのKademliaを参照してください）。リクエストされたピアがリクエストされたリソースを保持していない場合、通常、それ自体のDHTからフェッチされた追加のピアにクエリを「渡し」ます。

クエリを渡すことができる「ホップ」の数は通常制限されています。4は、JXTAタイプのネットワークの通常の数です。

ピアがリソースを保持している場合、完全な詳細で応答します。接続しているピアは、リソースを保持しているピアに（直接またはリレーを介して接続します-ここでは詳しく説明しません）接続して、フェッチを開始できます。

P2Pネットワークのリソース/サービスは、ネットワークアドレスに直接接続されていません。これらは分散されているため、これらの高度にスケーラブルなネットワークの優れた点です。

私も同じ質問に興味がありました。送信用のコードを読んだところ、次のことがわかりましたlibtrnasmission/tr-dht.c。

3248:     bootstrap_from_name( "dht.transmissionbt.com", 6881,
                               bootstrap_af(session) );

6回試行し、試行の間に40（！）秒待機します。設定ファイル（~/.config/transmissionUNIXの場合）を削除し、へのすべての通信をブロックすることでテストできdht.transmissionbt.com、何が起こるかを確認できます（少なくとも240秒待ちます）。

そのため、クライアントには最初からブートストラップノードが組み込まれているようです。もちろん、ネットワークに接続されると、そのブートストラップノードは不要になります。

ようやく仕様が見つかりました。初めてグーグルは助けにはならなかった。（wikiはメインサイトであるbittorrent.comにリンクしています。開発者のリンクをクリックしました。右側のbittorrent.orgタブに注目してください。そこから簡単にアクセスできます。ラベルが何であるかわからない場合にリンクを見つけるのは難しいです。クリックして離れます）。

すべてのトレントにはピアのネットワークがあるようです。トラッカーからピアを見つけ、セッション間で保持します。ネットワークを使用すると、ピアやその他のものを見つけることができます。マグネットリンクでの使用方法を読んだことはありませんが、新しいクライアントがピアを見つける方法は定義されていないようです。おそらく、一部は侵入されているか、クライアントに埋め込まれているホームサーバーまたは既知のトラッカーを使用して、ネットワーク内の最初のピアを取得しています。

私があなたの質問に答え始めたとき、私はあなたがマグネットスキームがどのように機能するかを尋ねていることに気づいていませんでした。bittorrentプロトコルに関連する部分がどのように生成されたかを知りたいと思っただけです。

マグネット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つの急流を別の急流と区別するものです。

ビットトレントプロトコルに関連するすべてのものは、依然としてトラッカーを中心に展開しています。それはまだ群れの間のコミュニケーションの主要な手段です。マグネットuriスキームは、bittorrentで使用するために特別に設計されたものではありません。これは、通信の代替形式として任意のP2Pプロトコルで使用されます。トレントを識別するもう1つの方法として、マグネットリンクを受け入れるように構成されたBittorrentクライアントは、.torrentファイルをダウンロードする必要がなくなります。マグネットuri trは、クライアントが参加できるようにそれを見つけるために、acker を指定する必要があります。他のプロトコルに関する情報を含めることができますが、ビットトレントプロトコルとは無関係です。最終的に、bittorrentプロトコルはトラッカーなしでは機能しません。

ピアのリストは、おそらくクライアントをアップグレードするトレントから読み込まれます（たとえば、クライアントをアップグレードするトレントにはトレントがあります）。全員が同じクライアントを使用している限り、アップグレードを共有する以外に選択肢がないため、問題はありません。