BT9G LABS / DHT Deep Dive #09

Dari Magnet Link ke Metadata File: Alur Lengkap Peer dan Metadata

Ikuti proses dari magnet link yang hanya membawa identitas konten hingga menemukan Peer, menegosiasikan ut_metadata, mengunduh metadata, dan memverifikasinya.

BT9G LabsTerbit 4 menit baca

BT9G Labs / DHT Deep Dive #09. Magnet link sengaja minimal: identitas lebih dulu, metadata lengkap diperoleh kemudian dari Peer yang mendukung extension terkait.

Dari Magnet Link ke Metadata File: Alur Lengkap Peer dan Metadata

Ringkasan cepat

  • Topik: Dari Magnet Link ke Metadata File: Alur Lengkap Peer dan Metadata
  • Kata kunci utama: magnet link, InfoHash, ut_metadata, metadata exchange, Peer discovery
  • 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

Magnet URI dapat membawa content identifier seperti BTIH atau BTMH dan parameter opsional seperti display name atau Tracker. Ia tidak harus membawa daftar file. Itulah alasan tautan magnet sangat ringkas dan dapat dibagikan tanpa file .torrent terpisah.

Untuk indexer, display name pada magnet tidak boleh dianggap sebagai metadata kanonik. Nama itu dapat hilang atau tidak tepercaya. Identitas hash adalah titik awal, lalu metadata yang diterima harus diverifikasi.

Temukan kandidat Peer terlebih dahulu

Klien menggunakan DHT, Tracker, atau sumber lain untuk memperoleh endpoint Peer. Kemudian ia mencoba koneksi dan BitTorrent handshake. Hanya Peer yang benar-benar mendukung extension protocol yang dapat diajak melakukan negosiasi ut_metadata.

Karena endpoint cepat kedaluwarsa, worker sebaiknya mencoba beberapa kandidat dengan concurrency terbatas. Catat alasan gagal seperti connect timeout, handshake reject, atau extension tidak tersedia agar scheduler dapat mengambil keputusan lebih baik.

Negosiasikan ut_metadata

BEP 10 extended handshake mengiklankan extension yang didukung dan mapping message ID. Jika Peer menawarkan ut_metadata, ia biasanya juga mengirim metadata_size. Klien kemudian meminta metadata dalam piece yang ukurannya ditentukan protokol.

Message ID tidak boleh di-hardcode secara global karena dinegosiasikan per koneksi. Parser harus menggunakan mapping dari handshake Peer tersebut.

Verifikasi sebelum indexing

Setelah semua piece terkumpul, gabungkan payload sesuai urutan lalu hitung kembali hash yang sesuai dengan identitas target. Metadata yang tidak cocok harus ditolak walaupun struktur bencode terlihat valid.

Baru setelah verifikasi, parser boleh mengekstrak nama, daftar file, ukuran, piece info, dan field lain untuk canonical storage dan search index. Urutan ini mencegah data palsu atau korup masuk ke hasil pencarian.

Sketsa implementasi

magnet(infohash)
   -> discover peers
   -> BitTorrent handshake
   -> BEP 10 extended handshake
   -> ut_metadata requests
   -> assemble info dictionary
   -> hash(info dictionary) == expected infohash ?
   -> parse and index

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

  • Mempercayai display name pada magnet sebagai metadata kanonik.
  • Menganggap semua Peer mendukung ut_metadata.
  • Meng-hardcode extended message ID.
  • Mengindeks metadata sebelum hash diverifikasi.

Artikel BT9G Labs terkait

Referensi

Artikel berikutnya: BEP 9 ut_metadata Dijelaskan: Mengambil Torrent Metadata dari Peer →

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