BT9G LABS / เจาะลึก DHT #09

จาก Magnet Link ไปสู่ File Metadata: Flow ของ Peer และ Metadata แบบครบถ้วน

ติดตามขั้นตอนจาก magnet link ที่มีเพียง content identity ไปสู่ Peer discovery, ut_metadata negotiation, metadata transfer และ hash verification

BT9G Labsเผยแพร่ 4 นาทีในการอ่าน

BT9G Labs / DHT Deep Dive #09. Magnet link ตั้งใจให้มีข้อมูลน้อย: identity มาก่อน ส่วน metadata แบบเต็มจะถูกดึงจาก Peer ภายหลัง

จาก Magnet Link ไปสู่ File Metadata: Flow ของ Peer และ Metadata แบบครบถ้วน

สรุปแบบรวดเร็ว

  • หัวข้อ: จาก Magnet Link ไปสู่ File Metadata: Flow ของ Peer และ Metadata แบบครบถ้วน
  • คีย์เวิร์ดหลัก: magnet link, InfoHash, ut_metadata, metadata exchange, Peer discovery
  • เหมาะสำหรับ: วิศวกร backend, นักวิจัยโปรโตคอล, search engineer และผู้พัฒนา BitTorrent
  • เป้าหมาย: อธิบายโปรโตคอลและสถาปัตยกรรมระบบอย่างแม่นยำพอที่จะนำไปใช้กับ discovery, metadata, indexing และ search pipeline ในระบบจริงได้

มุมมองระบบ

Magnet URI สามารถใส่ content identifier เช่น BTIH หรือ BTMH และ parameter เสริมอย่าง display name หรือ Tracker โดยไม่จำเป็นต้องมีรายชื่อไฟล์ นี่คือเหตุผลที่ magnet link มีขนาดเล็กและแชร์ได้โดยไม่ต้องแนบ .torrent

Indexer ไม่ควรเชื่อ display name ใน magnet ว่าเป็น canonical metadata เพราะอาจขาดหายหรือไม่ถูกต้อง Hash identity ต่างหากคือจุดเริ่มต้น

ต้องหา candidate Peer ก่อน

Client ใช้ DHT, Tracker หรือแหล่งอื่นเพื่อได้ Peer endpoint แล้วลอง connect และ BitTorrent handshake เฉพาะ Peer ที่รองรับ extension protocol จึงจะ negotiate ut_metadata ต่อได้

Endpoint เสื่อมอายุเร็ว Worker จึงควรลอง candidate หลายตัวด้วย concurrency จำกัด และบันทึกเหตุผลที่ fail แยกกัน

Negotiate ut_metadata

BEP 10 extended handshake โฆษณา extension ที่รองรับพร้อม mapping ของ message ID หาก Peer รองรับ ut_metadata มักส่ง metadata_size ด้วย จากนั้น client จะ request metadata เป็น piece

Message ID ไม่ควร hardcode เพราะ negotiate แยกต่อ connection

Verify ก่อน indexing

เมื่อได้ครบทุก piece ต้องประกอบ payload ตามลำดับและคำนวณ hash ใหม่ตาม target identity Metadata ที่ไม่ match ต้องถูกปฏิเสธแม้ bencode จะดูถูกต้อง

หลัง verification เท่านั้นจึงค่อย parse ชื่อไฟล์ file list ขนาด และ field อื่นลง canonical storage และ search 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 ไม่ควรวัดความสำเร็จจากจำนวน packet หรือจำนวน InfoHash ที่มองเห็นเพียงอย่างเดียว ควรแยก content identity, network observation, acquisition state, verified metadata และ search document ออกจากกันเป็นชั้นข้อมูลที่ชัดเจน ข้อมูลจาก DHT หรือ Peer ควรเก็บ source และ timestamp เสมอ เพื่อให้วิเคราะห์ bottleneck ได้ตั้งแต่ discovery, connection, handshake, extension negotiation, metadata transfer, verification, storage ไปจนถึง indexing

ข้อผิดพลาดที่พบบ่อย

  • เชื่อ display name ใน magnet ว่าเป็น canonical metadata
  • คิดว่า Peer ทุกตัวรองรับ ut_metadata
  • hardcode extended message ID
  • index metadata ก่อน hash verification

บทความ BT9G Labs ที่เกี่ยวข้อง

เอกสารอ้างอิง

บทความถัดไป: อธิบาย BEP 9 ut_metadata: การดึง Torrent Metadata จาก Peer →

บทความนี้อธิบายโปรโตคอล BitTorrent แบบสาธารณะและแนวทางเชิงวิศวกรรม การสังเกตเห็น Swarm ใดไม่ได้หมายความว่าเนื้อหานั้นยังใช้งานได้ ถูกต้อง หรือได้รับอนุญาตให้เผยแพร่