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

Seeder และ Leecher: ตัวเลขหมายถึงอะไรและวัดอย่างไร

ทำความเข้าใจนิยาม Seeder/Leecher วิธีที่ Tracker scrape นับ complete/incomplete และเหตุใด DHT จึงให้ตัวเลข global แบบแม่นยำไม่ได้

BT9G Labs / DHT Deep Dive #13. ตัวเลข Seeder และ Leecher ดูเรียบง่าย แต่ความหมายขึ้นกับแหล่งข้อมูลและเวลาที่สังเกตอย่างมาก

Seeder และ Leecher: ตัวเลขหมายถึงอะไรและวัดอย่างไร

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

  • หัวข้อ: Seeder และ Leecher: ตัวเลขหมายถึงอะไรและวัดอย่างไร
  • คีย์เวิร์ดหลัก: Seeder, Leecher, Tracker scrape, DHT, Torrent statistics
  • เหมาะสำหรับ: วิศวกร backend, นักวิจัยโปรโตคอล, search engineer และผู้พัฒนา BitTorrent
  • เป้าหมาย: อธิบายโปรโตคอลและสถาปัตยกรรมระบบอย่างแม่นยำพอที่จะนำไปใช้กับ discovery, metadata, indexing และ search pipeline ในระบบจริงได้

มุมมองระบบ

เริ่มจากนิยาม

Seeder โดยทั่วไปคือ Peer ที่มี content ครบและยังแบ่งปันอยู่ ส่วน Leecher คือ Peer ที่ยังมีไม่ครบ แต่ในโลกจริง Peer อาจหยุด client, เปลี่ยน network หรือรายงานสถานะไม่สมบูรณ์

ดังนั้นตัวเลขบนเว็บไซต์เป็น snapshot หรือ estimate จากวิธีวัดหนึ่ง ไม่ใช่ข้อเท็จจริงถาวรของทั้ง Internet

Counter จาก Tracker scrape

Tracker ที่รองรับ scrape สามารถตอบ complete, incomplete และบางครั้ง downloaded ต่อ InfoHash ได้ นี่เป็นแหล่งตรงที่สุดสำหรับ label Seeder/Leecher แต่ครอบคลุมเฉพาะ population ที่ Tracker นั้นมองเห็น

หาก Torrent ใช้หลาย Tracker ไม่ควรนำตัวเลขมาบวกตรง ๆ เพราะ Peer เดียวอาจอยู่ในหลาย Tracker

ทำไม DHT ไม่ให้ exact seeder count

BEP 5 get_peers ส่ง Peer endpoint หรือ node ที่ใกล้ target มากกว่า ไม่มี field global ที่บอกจำนวน complete/incomplete Peer ทั้ง Swarm Crawler เองก็เห็นเพียง subset ของ network

การ classify Seeder จาก DHT ต้องมี connection และ state เพิ่ม และยังไม่รับประกัน coverage ครบ

Product semantics ที่ตรงความจริงกว่า

ถ้าข้อมูลมาจาก Tracker ควรแสดง source กับ timestamp หากมีเพียง DHT activity ควรใช้ label เช่น 'recent peers observed' หรือ 'recent activity' แทน 'global seeders'

ความโปร่งใสของ source ช่วยให้ผู้ใช้เข้าใจว่าตัวเลขเป็น operational signal ไม่ใช่การสำรวจทั้ง Internet

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

{
  "source": "tracker_scrape",
  "infohash": "...",
  "complete": 142,
  "incomplete": 37,
  "observed_at": "2026-09-16T03:00:00Z"
}

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

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

  • แสดง Seeder/Leecher โดยไม่ระบุ source หรือ timestamp
  • บวกตัวเลขหลาย Tracker โดยไม่ dedup
  • คิดว่า DHT ให้ exact seeder count
  • ใช้ activity count แทนจำนวน Seeder

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

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


บทความถัดไป: ทำไมการดึง Torrent Metadata จึงล้มเหลว: 10 สาเหตุจริงและโมเดล Retry ที่ดีกว่า →

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