BT9G LABS / DHT 심층 분석 #09

Magnet Link가 Metadata가 되는 과정: Peer Discovery부터 BEP 9/10까지

Magnet의 InfoHash에서 DHT Peer discovery, BEP 10 협상, BEP 9 Metadata 수집까지 전체 흐름을 설명합니다.

BT9G Labs게시일 2026-09-163 분 읽기

BT9G Labs / DHT Deep Dive #09. 해시 중심의 Magnet URI가 어떻게 파일명, 크기, 디렉터리 정보를 가진 검증된 Metadata로 변하는지 살펴봅니다.

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 URIDHT / TrackerPeerBEP 10 HandshakeBEP 9 Metadata

Magnet URI → DHT / Tracker; DHT / Tracker → Peer; Peer → BEP 10 Handshake; BEP 10 Handshake → BEP 9 Metadata

Magnet은 의도적으로 불완전하다

일반적인 Magnet URI의 핵심은 xt=urn:btih:... 같은 content identifier입니다. display name이나 Tracker가 포함될 수 있지만 완전한 info dictionary를 담는 것은 아닙니다. 따라서 Magnet만으로 신뢰할 수 있는 file list와 total size를 알 수 없습니다.

Magnet은 identity만으로 discovery를 시작하고 부족한 Metadata는 나중에 네트워크에서 얻도록 설계되었습니다.

먼저 Peer 후보를 찾는다

DHT, Tracker 등에서 endpoint를 얻고 BitTorrent handshake로 같은 InfoHash를 다루는 Peer인지 확인합니다. endpoint는 이미 offline일 수 있으므로 여러 후보를 병렬 시도하는 것이 일반적입니다.

DHT의 get_peers는 Peer 후보를 주는 단계이며 Metadata 자체를 반환하지 않습니다.

BEP 10 → BEP 9 → 검증

extended handshake를 통해 ut_metadata 지원 여부, connection-local message ID, metadata_size 등을 확인합니다. 이후 BEP 9로 Metadata pieces를 받아 조립합니다.

최종 바이트가 기대하는 content identity와 일치하는지 반드시 검증하고, 통과한 결과만 canonical storage와 검색 인덱스로 전달해야 합니다.

구현 스케치

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 같은 인덱싱 시스템에서는 이벤트 수 자체보다 콘텐츠 식별자, 수명이 짧은 네트워크 관측값, 수집 상태, 검색용 문서를 분리하는 것이 중요합니다. DHT나 Peer에서 얻은 필드에는 출처와 타임스탬프를 남기고, discovery, 연결, handshake, 확장 지원, Metadata 수집, 검증, 저장, 검색 반영을 단계별로 측정해야 실제 병목을 찾을 수 있습니다.

흔한 오해

Magnet에 완전한 파일 목록이 있다고 생각하는 것.
get_peers를 Metadata API로 보는 것.
ut_metadata message ID를 고정하는 것.
해시 검증 없이 Metadata를 저장하는 것.

참고 자료

다음 글: BEP 9 ut_metadata 해설: Peer에서 Torrent Metadata 가져오기 →

이 글은 공개 BitTorrent 프로토콜의 동작을 엔지니어링 및 연구 목적으로 설명하며, 관측된 모든 Swarm이 사용 가능하거나 유효하거나 재배포 허가를 받았음을 의미하지 않습니다.