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

เจาะลึก InfoHash: BitTorrent v1, v2, Magnet Link, BTIH และ BTMH

เรียนรู้ว่า InfoHash ถูกสร้างอย่างไรใน BitTorrent v1 และ v2 แตกต่างกันอย่างไรระหว่าง BTIH กับ BTMH และมีผลต่อ indexing อย่างไร

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

BT9G Labs / DHT Deep Dive #04. InfoHash คือ cryptographic identity ของ Torrent metadata ดังนั้นการคำนวณและจัดเก็บให้ถูกต้องเป็นเรื่องสำคัญมากสำหรับ search engine

เจาะลึก InfoHash: BitTorrent v1, v2, Magnet Link, BTIH และ BTMH

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

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

มุมมองระบบ

Info dictionary คือขอบเขตของ identity

ในไฟล์ .torrent ส่วน info เป็นตัวกำหนด identity ของ Torrent Hash ต้องคำนวณจาก bencoded representation ที่ถูกต้อง ไม่ใช่ชื่อที่แสดงผลหรือ JSON หลัง parse แล้ว การเปลี่ยน byte ที่มีความหมายใน info dictionary จะสร้าง identity ใหม่

Parser จึงไม่ควร parse แล้ว serialize ใหม่ด้วยรูปแบบอื่นก่อนคำนวณ hash ควรเก็บ raw info bytes หรือวิธีที่ตรวจสอบกับ payload เดิมได้

v1 และ namespace BTIH

BitTorrent v1 ใช้ SHA-1 กับ bencoded info dictionary ได้ค่า 20 byte Magnet link แบบคลาสสิกใช้ xt=urn:btih:... และมักแสดงเป็น hex หรือ Base32

ระบบเก่าหลายแห่งใช้ string hex 40 ตัวเป็น primary key วิธีนี้สะดวกสำหรับ v1 แต่ไม่ควรกลายเป็นข้อสมมติถาวรว่าทุก BitTorrent identity ต้องมีรูปแบบเดียวกัน

v2, SHA-256 และ BTMH

BitTorrent v2 ใช้ SHA-256 และ Merkle structure สำหรับการตรวจสอบเนื้อหา Magnet รุ่นใหม่สามารถใช้ multihash ผ่าน namespace BTMH ส่วน hybrid Torrent อาจรองรับทั้ง v1 และ v2 พร้อมกัน

ฐานข้อมูลจึงควรเก็บ hash type และ algorithm อย่างชัดเจน แทนที่จะใช้เพียง CHAR(40) ช่องเดียว

ผลต่อระบบ indexing

Canonical identity, magnet representation, raw metadata และ search document ควรแยกจากกัน ขณะ ingest ต้องคำนวณ hash จาก metadata ที่ได้รับใหม่ตาม version ที่ถูกต้องแล้วเทียบกับ target ก่อนบันทึกว่า valid

หากรองรับ v1, v2 และ hybrid ควรเชื่อม identity ที่เกี่ยวข้องโดยไม่รวมผิด และไม่ควร dedup จากชื่อไฟล์เพียงอย่างเดียว

ตัวอย่างการนำไปใช้

import hashlib

def v1_infohash(raw_bencoded_info: bytes) -> bytes:
    return hashlib.sha1(raw_bencoded_info).digest()

def v2_infohash(raw_bencoded_info: bytes) -> bytes:
    return hashlib.sha256(raw_bencoded_info).digest()

บันทึกเชิงวิศวกรรมจาก 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

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

  • คำนวณ InfoHash จาก JSON หลัง parse แทน raw bencoded info dictionary
  • สมมติว่า InfoHash ทุกแบบมี hex 40 ตัว
  • รวม v1 กับ v2 โดยไม่เก็บ hash type
  • ถือชื่อ Torrent เป็น canonical identity

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

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

บทความถัดไป: อธิบายข้อความ DHT ใน BEP 5: ping, find_node, get_peers และ announce_peer →

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