BT9G LABS / DHT Deep Dive #10

BEP 9 ut_metadata Dijelaskan: Mengambil Torrent Metadata dari Peer

Pelajari lifecycle BEP 9, metadata_size, request/data/reject, pembagian piece, verifikasi hash, dan scheduling multi-Peer.

BT9G LabsTerbit 3 menit baca

BT9G Labs / DHT Deep Dive #10. BEP 9 memungkinkan klien memperoleh info dictionary dari Peer tanpa memiliki file .torrent terlebih dahulu.

BEP 9 ut_metadata Dijelaskan: Mengambil Torrent Metadata dari Peer

Ringkasan cepat

  • Topik: BEP 9 ut_metadata Dijelaskan: Mengambil Torrent Metadata dari Peer
  • Kata kunci utama: BEP 9, ut_metadata, torrent metadata, metadata_size, BitTorrent extension
  • Untuk pembaca: engineer backend, peneliti protokol, search engineer, dan pengembang implementasi BitTorrent
  • Tujuan: Menjelaskan protokol dan desain sistem dengan cukup presisi agar dapat diterapkan pada pipeline discovery, metadata, indexing, dan search di dunia nyata.

Gambaran sistem

Apa yang ditransfer BEP 9

ut_metadata mentransfer bencoded info dictionary yang diperlukan untuk membangun metadata Torrent, bukan payload file konten. Ukuran metadata diberitahukan melalui extended handshake dan data dibagi menjadi piece berukuran terbatas.

Bagi indexer, ini sangat berguna karena InfoHash dari magnet atau DHT dapat diubah menjadi struktur nama/file/size tanpa mengunduh data konten Torrent itu sendiri.

Lifecycle pesan

Klien meminta nomor piece tertentu dengan pesan request. Peer dapat mengirim data atau reject. Setelah menerima piece, klien menandainya selesai dan menjadwalkan piece lain sampai seluruh metadata terkumpul. Timeout dan disconnect harus ditangani per piece dan per Peer.

Implementasi sebaiknya membatasi jumlah request inflight serta ukuran metadata maksimum untuk mencegah konsumsi memori yang tidak terkendali.

Validasi tidak boleh dilewati

Metadata yang lengkap belum otomatis benar. Untuk v1, raw bencoded info dictionary harus menghasilkan SHA-1 yang sama dengan InfoHash target. Untuk mode lain, gunakan aturan hash yang sesuai dengan versi protokol.

Jika verifikasi gagal, jangan menyimpan hasil tersebut sebagai metadata valid. Catat Peer sumber dan kegagalan agar reputasi/telemetri dapat membantu memilih sumber pada percobaan berikutnya.

Scheduling di banyak Peer

Satu Swarm dapat memiliki beberapa Peer yang mendukung ut_metadata. Scheduler dapat mencoba kandidat secara paralel terbatas, berpindah Peer jika piece lambat, atau mengambil seluruh metadata dari satu Peer yang terbukti cepat.

Hindari parallelism tanpa batas. Bottleneck sering berupa socket, file descriptor, NAT, atau bandwidth, bukan CPU. Ukur success rate dan latency per tahap sebelum menaikkan concurrency.

Sketsa implementasi

{"msg_type": 0, "piece": 0}          // request
{"msg_type": 1, "piece": 0,
 "total_size": 48321}                // data header, followed by bytes
{"msg_type": 2, "piece": 0}          // reject

Catatan engineering BT9G Labs

Untuk sistem indeks seperti BT9G, metrik yang paling berguna bukan sekadar jumlah paket atau jumlah InfoHash yang terlihat. Pisahkan identitas konten, observasi jaringan, status akuisisi, metadata terverifikasi, serta dokumen pencarian menjadi lapisan data yang berbeda. Simpan sumber dan waktu observasi untuk data yang datang dari DHT atau Peer. Dengan begitu, bottleneck dapat dilacak dari tahap discovery, koneksi, handshake, negosiasi extension, pengambilan metadata, validasi, penyimpanan, hingga indexing.

Kesalahan umum

  • Mengira BEP 9 mengunduh isi file Torrent.
  • Tidak membatasi metadata_size.
  • Menerima metadata tanpa verifikasi hash.
  • Membuka koneksi sebanyak mungkin tanpa backpressure.

Artikel BT9G Labs terkait

Referensi

Artikel berikutnya: BEP 10 Extension Protocol: Negosiasi Fitur BitTorrent Tanpa Merusak Kompatibilitas →

Artikel ini menjelaskan protokol BitTorrent publik dan pola engineering. Observasi terhadap sebuah Swarm tidak berarti kontennya tersedia, valid, atau diizinkan untuk didistribusikan.