BT9G LABS / DHT Deep Dive #07

Mengapa DHT Melihat Begitu Banyak InfoHash? Memahami Swarm Discovery pada Skala Internet

Pahami mengapa stream DHT berisi sangat banyak InfoHash, bagaimana aktivitas Swarm menghasilkan observasi, serta mengapa deduplikasi dan ranking sangat penting.

BT9G LabsTerbit 4 menit baca

BT9G Labs / DHT Deep Dive #07. Volume InfoHash di DHT berasal dari aktivitas terdistribusi yang berulang, bukan dari satu registry global yang menerbitkan daftar Torrent baru.

Mengapa DHT Melihat Begitu Banyak InfoHash? Memahami Swarm Discovery pada Skala Internet

Ringkasan cepat

  • Topik: Mengapa DHT Melihat Begitu Banyak InfoHash? Memahami Swarm Discovery pada Skala Internet
  • Kata kunci utama: InfoHash discovery, DHT scale, Swarm activity, deduplication, 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

InfoHash muncul karena aktivitas, bukan registry pusat

DHT tidak memiliki feed resmi 'Torrent baru'. InfoHash terlihat ketika klien mencari Peer, mengumumkan partisipasi, atau ketika crawler melakukan lookup yang memunculkan target terkait. Satu Swarm aktif dapat menghasilkan banyak observasi yang sama dari lokasi dan waktu berbeda.

Akibatnya, jumlah event mentah jauh lebih besar daripada jumlah identitas unik. Sistem ingest harus menganggap event sebagai sinyal aktivitas dan InfoHash sebagai identitas yang perlu didedup secara terpisah.

Mengapa stream mengandung noise

Tidak semua target yang terlihat akan menghasilkan metadata. Sebagian mungkin berasal dari Swarm yang sudah sepi, input acak, software eksperimen, scanning, atau Peer yang hanya muncul sebentar. Endpoint juga dapat stale sebelum worker sempat terhubung.

Membuang semua hash yang gagal pada percobaan pertama akan kehilangan konten yang hanya sedang tidak aktif. Sebaliknya, mencoba semua hash terus-menerus akan membuang bandwidth. Diperlukan scheduler berbasis evidence dan backoff.

Deduplikasi mengubah ekonomi sistem

Jika satu InfoHash terlihat ratusan kali, metadata seharusnya tidak diambil ratusan kali. Hot-path dedup dapat menggabungkan observasi ke satu record identitas, memperbarui last_seen dan activity_count, lalu hanya menjadwalkan akuisisi ketika status memang membutuhkannya.

Bloom filter atau cache Redis bisa menahan duplikat panas, tetapi database durable tetap dibutuhkan sebagai source of truth. Filter probabilistik tidak boleh menjadi satu-satunya tempat menentukan apakah hash pernah diproses.

Aktivitas adalah sinyal ranking, bukan popularitas absolut

Frekuensi observasi dapat membantu memperkirakan bahwa suatu Swarm sedang aktif, tetapi bias crawler, lokasi jaringan, jam pengamatan, dan implementasi klien mempengaruhi angka tersebut. Karena itu activity_count bukan jumlah pengguna global.

Gunakan aktivitas sebagai salah satu fitur ranking bersama freshness, keberhasilan koneksi, metadata quality, jumlah sumber observasi, dan sinyal lain. Label UI sebaiknya menjelaskan metrik dengan jujur, misalnya 'recently observed' daripada 'global popularity'.

Sketsa implementasi

INSERT INTO infohash_observation(infohash, first_seen, last_seen, seen_count)
VALUES (?, NOW(), NOW(), 1)
ON DUPLICATE KEY UPDATE
  last_seen = VALUES(last_seen),
  seen_count = seen_count + 1;

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

  • Menyamakan jumlah event DHT dengan jumlah Torrent unik.
  • Menganggap setiap InfoHash yang terlihat pasti memiliki metadata yang bisa diambil.
  • Mengambil metadata ulang setiap kali hash yang sama muncul.
  • Menampilkan activity count seolah-olah jumlah pengguna global yang presisi.

Artikel BT9G Labs terkait

Referensi

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

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