BEP 10 Extension Protocol: BitTorrent Negotiate ฟีเจอร์ใหม่โดยไม่ทำลาย Compatibility

BT9G Labs / DHT Deep Dive #11. BEP 10 ให้ BitTorrent เพิ่มความสามารถใหม่โดยไม่ต้องเปลี่ยน wire protocol หลักทุกครั้ง

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

• หัวข้อ: BEP 10 Extension Protocol: BitTorrent Negotiate ฟีเจอร์ใหม่โดยไม่ทำลาย Compatibility
• คีย์เวิร์ดหลัก: BEP 10, BitTorrent extension protocol, extended handshake, ut_metadata, capability negotiation
• เหมาะสำหรับ: วิศวกร backend, นักวิจัยโปรโตคอล, search engineer และผู้พัฒนา BitTorrent
• เป้าหมาย: อธิบายโปรโตคอลและสถาปัตยกรรมระบบอย่างแม่นยำพอที่จะนำไปใช้กับ discovery, metadata, indexing และ search pipeline ในระบบจริงได้

มุมมองระบบ

ปัญหาเรื่อง compatibility

โปรโตคอล P2P มีอายุยาวและ client แต่ละตัวอัปเดตไม่พร้อมกัน หากทุก feature ใหม่ต้องเปลี่ยน wire protocol แบบ incompatible ระบบจะกระจัดกระจายเร็ว BEP 10 จึงสร้างชั้น extension ที่ negotiate ได้หลัง basic handshake

Client ที่ไม่รู้จัก extension ยังใช้ protocol หลักได้ ส่วนคู่ที่รองรับตรงกันก็เปิดฟีเจอร์เพิ่ม

Extended handshake

เมื่อ negotiate extension bit ใน BitTorrent handshake แล้ว Peer สามารถส่ง extended handshake Dictionary m map ชื่อ extension เช่น ut_metadata ไปยัง message ID เฉพาะของ connection นั้น Field อื่นอาจมี client version หรือ metadata_size

Message ID เป็นผลจาก negotiation ไม่ใช่ constant ที่ใช้เหมือนกันทั่วโลก

Capability เปลี่ยนไปตาม Peer

Peer หนึ่งอาจรองรับ ut_metadata อีก Peer อาจรองรับ extension อื่น และบางตัวอาจไม่รองรับ extension protocol เลย State machine ต้องตรวจ capability ก่อนส่ง extension message

Parser ควรยอมรับ field ใหม่ที่ไม่รู้จักหาก format ถูกต้อง เพื่อให้รองรับวิวัฒนาการของ ecosystem

เหตุใด indexer จึงต้องสนใจ

Metadata acquisition พึ่ง BEP 10 และ BEP 9 โดยตรง หาก extended handshake ผิด Worker จะไม่รู้ ID ของ ut_metadata หรือ metadata size ความล้มเหลวจำนวนมากที่ดูเหมือน metadata timeout จริง ๆ อาจเกิดที่ negotiation

ควรแยก metric ของ connect, basic handshake, extension handshake, capability detection, transfer และ verification

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

Base handshake
  reserved bit says: extension protocol supported
        |
        v
Extended handshake
  m = { "ut_metadata": 3, "ut_pex": 1 }
  metadata_size = 48321
        |
        v
Extended message 3 now means ut_metadata for this connection

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

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

• คิดว่า Peer ทุกตัวรองรับ extension protocol
• hardcode message ID ของ ut_metadata
• fail เมื่อพบ extension field ที่ไม่รู้จักแต่ถูกต้อง
• รวมความล้มเหลวทุกแบบไว้ใน metadata timeout metric เดียว

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

• จาก Magnet Link ไปสู่ File Metadata: Flow ของ Peer และ Metadata แบบครบถ้วน
• อธิบาย BEP 9 ut_metadata: การดึง Torrent Metadata จาก Peer
• Tracker vs DHT vs PEX: เปรียบเทียบสามกลไก Peer Discovery ของ BitTorrent
• Seeder และ Leecher: ตัวเลขหมายถึงอะไรและวัดอย่างไร

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

• BEP 10 - Extension Protocol
• BEP 9 - Extension for Peers to Send Metadata Files
• BEP 11 - Peer Exchange (PEX)

บทความถัดไป: Tracker vs DHT vs PEX: เปรียบเทียบสามกลไก Peer Discovery ของ BitTorrent →

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