BT9G LABS / DHT 詳解 #09

Magnet LinkからMetadataへ:Peer DiscoveryとBEP 9/10の完全フロー

Magnet の InfoHash から DHT、Peer connection、BEP 10、BEP 9 を経て Metadata を得る流れを追います。

BT9G Labs / DHT Deep Dive #09. ハッシュ中心の Magnet URI が、最終的にファイル名・サイズ・ディレクトリ情報へ変わる仕組みを解説します。

Magnet LinkからMetadataへ:Peer DiscoveryとBEP 9/10の完全フロー

クイックサマリー

  • テーマ: Magnet LinkからMetadataへ:Peer DiscoveryとBEP 9/10の完全フロー
  • 主要キーワード: Magnet link, Torrent Metadata, BEP 9, BEP 10, InfoHash
  • 対象読者: バックエンドエンジニア、プロトコル研究者、検索エンジニア、BitTorrent 実装者
  • 目的: DHT と BitTorrent の仕組みを、実際のクローラ・インデックス・検索基盤の設計判断に使える精度で説明すること。

システム構成

Magnet は意図的に不完全

典型的な Magnet URI の中心は xt=urn:btih:... などの content identifier です。display name や Tracker が付く場合もありますが、完全な info dictionary を持つとは限りません。

そのため Magnet だけでは信頼できる file list や total size は分からず、ネットワークから不足 Metadata を取得します。

まず Peer candidates を得る

DHT、Tracker などから endpoint を取得し、BitTorrent handshake で同じ InfoHash を扱う Peer か確認します。endpoint はすでに offline の場合も多く、実用システムは複数候補を並列に試します。

DHT の get_peers は候補を見つけるためのもので、Metadata 自体は返しません。

BEP 10 → BEP 9 → 検証

extended handshake で ut_metadata の対応と connection-local message ID、場合によっては metadata_size を確認します。その後 BEP 9 で Metadata pieces を取得し、全体を再構成します。

最後に期待する content identity と一致するかハッシュ検証し、成功したものだけを canonical storage と検索 index へ進めます。

実装スケッチ

magnet(infohash)
   -> discover peers
   -> BitTorrent handshake
   -> BEP 10 extended handshake
   -> ut_metadata requests
   -> assemble info dictionary
   -> hash(info dictionary) == expected infohash ?
   -> parse and index

BT9G Labs エンジニアリングノート

BT9G のようなインデックス基盤では、イベント件数そのものより、コンテンツ ID、短命なネットワーク観測、取得状態、検索用ドキュメントを分離することが重要です。DHT や Peer から得た値には取得元と時刻を持たせ、discovery、接続、handshake、拡張対応、Metadata 取得、検証、保存、検索反映を段階別に計測すると、実際のボトルネックを特定しやすくなります。

よくある誤解

  • Magnet に完全な file list が含まれると思う。
  • get_peers を Metadata API とみなす。
  • ut_metadata message ID を固定値にする。
  • ハッシュ検証せず Metadata を保存する。

関連する BT9G Labs 記事

参考資料


次の記事: BEP 9 ut_metadata解説:PeerからTorrent Metadataを取得する仕組み →

本記事は公開 BitTorrent プロトコルの挙動を技術・研究目的で解説するものであり、観測されたすべての Swarm が利用可能、正当、または再配布を許可されていることを意味しません。