BT9G LABS / DHT a fondo #13

Seeders y Leechers: qué significan los números y cómo se miden

Definiciones, Tracker scrape, limitaciones de DHT y por qué el tamaño global de un Swarm es difícil de medir exactamente.

BT9G LabsPublicado 3 min de lectura

BT9G Labs / DHT Deep Dive #13. Separa conceptos de protocolo, mediciones de Tracker y cifras de producto para no presentar estimaciones como hechos globales exactos.

Seeders y Leechers: qué significan los números y cómo se miden

Resumen rápido

  • Tema: Seeders y Leechers: qué significan los números y cómo se miden
  • Palabras clave: Seeders, Leechers, Tracker scrape, Swarm size, DHT
  • Audiencia: ingenieros backend, investigadores de protocolos, ingenieros de búsqueda e implementadores de BitTorrent
  • Objetivo: Explicar el mecanismo con suficiente precisión como para apoyar decisiones reales de arquitectura de crawling, indexación y búsqueda.

Vista del sistema

Definiciones y origen de la cifra

Un Seeder normalmente posee el contenido completo y continúa subiendo; un Leecher aún no lo ha completado. Pero el número visible depende de quién lo mide. No existe una autoridad central que reúna en tiempo real el estado de todos los clientes BitTorrent.

Por eso una cifra sin source ni timestamp tiene semántica incompleta.

Qué mide un Tracker scrape

Un Tracker compatible puede devolver complete, incomplete y downloaded. Son estadísticas útiles del conjunto que ese Tracker conoce, pero un Torrent puede usar varios Tracker, DHT y PEX, con conjuntos de Peer que se solapan.

No se pueden sumar todos los scrape counts sin deduplicación.

Por qué DHT no da Seeders exactos

get_peers devuelve endpoints pero no indica si cada Peer posee el 100% del contenido. Un lookup tampoco enumera todos los participantes mundiales. Por ello es más honesto mostrar recent peers observed, last active o activity score cuando la fuente es DHT.

Si se muestran datos de Tracker, conviene etiquetar la fuente y el momento de la muestra.

Esquema de implementación

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

Notas de ingeniería de BT9G Labs

En un indexador como BT9G importa más separar correctamente la identidad del contenido, las observaciones de red de corta duración, el estado de adquisición y los documentos de búsqueda que maximizar el número bruto de eventos. Cada campo derivado de DHT o de un Peer debería conservar su fuente y marca temporal, y las métricas deberían dividirse por etapas: discovery, conexión, handshake, soporte de extensiones, obtención de Metadata, validación, almacenamiento e indexación.

Errores comunes

  • Tratar cualquier Peer activo como Seeder.
  • Sumar scrape de varios Tracker directamente.
  • Inferir Seeders exactos del número de endpoints DHT.
  • Mostrar un contador sin fuente ni tiempo de medición.

Artículos relacionados de BT9G Labs

Referencias

Siguiente artículo: Por qué falla la obtención de Torrent Metadata: 10 causas reales y un mejor modelo de retry →

Este artículo describe el comportamiento de protocolos públicos de BitTorrent con fines de ingeniería e investigación; no implica que todo Swarm observado esté disponible, sea válido o esté autorizado para su redistribución.