BT9G LABS / DHT em profundidade #13
Seeders e Leechers: o que os números significam e como são medidos
Definições de Seeder/Leecher, Tracker scrape, limitações da DHT e por que o tamanho global de um Swarm é difícil de medir.
BT9G Labs / DHT Deep Dive #13. Separe conceitos de protocolo, medições de Tracker e números de produto para não apresentar estimativas como fatos globais exatos.
Resumo rápido
- Tema: Seeders e Leechers: o que os números significam e como são medidos
- Palavras-chave: Seeders, Leechers, Tracker scrape, Swarm size, DHT
- Público: engenheiros backend, pesquisadores de protocolos, engenheiros de busca e implementadores de BitTorrent
- Objetivo: Explicar o mecanismo com precisão suficiente para orientar decisões reais de arquitetura de crawling, indexação e busca.
Visão do sistema
Definições e origem da medição
Seeder normalmente possui o conteúdo completo e continua enviando; Leecher ainda não terminou. Mas o número exibido depende de quem mede. Não existe um serviço central que observe em tempo real todos os clientes BitTorrent do mundo.
Por isso source e timestamp fazem parte do significado da métrica.
O que mede um Tracker scrape
Um Tracker compatível pode retornar complete, incomplete e downloaded. Isso é útil para o conjunto conhecido por aquele Tracker, mas um Torrent pode usar vários Tracker, DHT e PEX, com Peer sobrepostos.
Não é correto simplesmente somar todos os scrape counts.
Por que DHT não dá Seeders exatos
get_peers retorna endpoints, mas não indica se cada Peer possui 100% do conteúdo. Um lookup também não enumera todos os participantes globais. Em dados derivados de DHT, termos como recent peers observed, last active ou activity score são mais fiéis ao que foi realmente medido.
Quando dados de Tracker forem exibidos, fonte e horário da amostra ajudam a evitar interpretação errada.
Esboço de implementação
{
"source": "tracker_scrape",
"infohash": "...",
"complete": 142,
"incomplete": 37,
"observed_at": "2026-09-16T03:00:00Z"
}Notas de engenharia do BT9G Labs
Em um indexador como o BT9G, é mais importante separar corretamente a identidade do conteúdo, observações de rede de curta duração, estado de aquisição e documentos de busca do que maximizar o número bruto de eventos. Campos derivados de DHT ou de um Peer devem manter origem e timestamp, e as métricas devem ser divididas por etapas: discovery, conexão, handshake, suporte a extensões, obtenção de Metadata, validação, armazenamento e indexação.
Erros comuns
- Tratar todo Peer ativo como Seeder.
- Somar scrapes de vários Tracker diretamente.
- Inferir Seeders exatos do número de endpoints DHT.
- Exibir contagem sem fonte e timestamp.
Artigos relacionados do BT9G Labs
- BEP 10 Extension Protocol: como expandir BitTorrent sem quebrar compatibilidade
- Tracker vs DHT vs PEX: comparação de três mecanismos de Peer Discovery
- Por que a obtenção de Torrent Metadata falha: 10 causas reais e um modelo de retry melhor
- Arquitetura de um DHT Crawler de alto desempenho: filas e backpressure
Referências
Este artigo descreve o comportamento de protocolos públicos do BitTorrent para fins de engenharia e pesquisa; não implica que todo Swarm observado esteja disponível, seja válido ou autorizado para redistribuição.