BT9G LABS / DHT Deep Dive #08

Cara DHT Crawler Menemukan InfoHash: Lookup Aktif, Observasi, dan Desain Bertanggung Jawab

Pelajari pola discovery InfoHash pada DHT crawler, pemisahan discovery dan metadata acquisition, serta cara membangun ingestion path yang efisien dan sopan.

BT9G LabsTerbit 4 menit baca

BT9G Labs / DHT Deep Dive #08. Crawler yang sehat memisahkan observasi DHT berkecepatan tinggi dari pekerjaan metadata yang lebih lambat dan mahal.

Cara DHT Crawler Menemukan InfoHash: Lookup Aktif, Observasi, dan Desain Bertanggung Jawab

Ringkasan cepat

  • Topik: Cara DHT Crawler Menemukan InfoHash: Lookup Aktif, Observasi, dan Desain Bertanggung Jawab
  • Kata kunci utama: DHT crawler, InfoHash discovery, active lookup, crawler architecture, BitTorrent
  • 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

Discovery dan acquisition adalah dua pipeline berbeda

Menemukan InfoHash biasanya jauh lebih murah daripada memperoleh metadata lengkap. Event discovery hanya memerlukan parsing paket dan pencatatan target, sedangkan metadata membutuhkan Peer discovery, TCP/µTP connection, handshake, extension negotiation, transfer beberapa piece, dan verifikasi hash.

Jika kedua pekerjaan dilakukan sinkron dalam satu worker, input DHT mudah tersumbat oleh koneksi lambat. Arsitektur yang lebih baik menulis hash ke ledger/queue dengan cepat lalu menyerahkan akuisisi ke worker pool terpisah.

Strategi aktif dan observasional

Crawler dapat mempelajari jaringan melalui lookup yang memang diperlukan untuk routing, serta mengamati target yang muncul pada request DHT yang diterima. Masing-masing memberi bias berbeda. Active lookup dikendalikan crawler, sedangkan observation mencerminkan traffic yang kebetulan mencapai node crawler.

Jangan menganggap satu sudut pandang mewakili seluruh DHT. Beberapa collector di jaringan berbeda dapat meningkatkan cakupan, tetapi hasil tetap perlu didedup dan diberi provenance.

Hot path ingestion

Jalur UDP sebaiknya sesingkat mungkin: parse, validasi, normalisasi key, catat sumber/waktu, lakukan dedup murah, lalu enqueue. Operasi database berat, enrichment, dan metadata fetch tidak seharusnya memblokir event loop paket.

Gunakan bounded queue dan backpressure. Ketika downstream tertinggal, lebih baik memiliki kebijakan sampling atau drop yang terukur daripada membuat memori tumbuh tanpa batas sampai proses crash.

Perilaku jaringan yang bertanggung jawab

Rate limit, timeout yang wajar, ukuran paket sesuai protokol, dan tidak mengirim traffic palsu adalah bagian dari kualitas engineering. Crawler tidak perlu membanjiri node dengan query duplikat untuk meningkatkan angka discovery.

Hindari announce_peer jika crawler tidak benar-benar menjadi Peer untuk konten tersebut. Tujuan observasi adalah memahami protokol dan metadata publik yang tersedia, bukan memanipulasi state jaringan.

Sketsa implementasi

func handlePacket(pkt []byte, from *net.UDPAddr) {
    msg, err := krpc.Parse(pkt)
    if err != nil { return }
    routing.Observe(msg.NodeID, from)
    if ih, ok := msg.InfoHash(); ok {
        observer.TryEmit(HashEvent{Hash: ih, SeenAt: time.Now()})
    }
}

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

  • Menjalankan metadata fetch langsung di hot path UDP.
  • Menganggap satu collector melihat seluruh DHT.
  • Menggunakan queue tanpa batas saat downstream melambat.
  • Mengirim query atau announce berlebihan hanya untuk meningkatkan volume data.

Artikel BT9G Labs terkait

Referensi

Artikel berikutnya: Dari Magnet Link ke Metadata File: Alur Lengkap Peer dan Metadata →

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