BT9G LABS / DHT em profundidade #10

BEP 9 ut_metadata explicado: obtendo Torrent Metadata de Peer

Message types, pieces, validação e scheduling do BEP 9 para crawlers de alto volume.

BT9G LabsPublicado 3 min de leitura

BT9G Labs / DHT Deep Dive #10. Entenda request/data/reject e por que a etapa crítica é confirmar a identidade correta após montar a Metadata.

BEP 9 ut_metadata explicado: obtendo Torrent Metadata de Peer

Resumo rápido

  • Tema: BEP 9 ut_metadata explicado: obtendo Torrent Metadata de Peer
  • Palavras-chave: BEP 9, ut_metadata, Torrent Metadata, metadata piece, BitTorrent
  • 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

O que o BEP 9 transfere

ut_metadata transfere principalmente o info dictionary bencoded, não todos os campos externos do .torrent. Os dados são divididos em pieces e metadata_size permite calcular o total esperado.

O scheduler precisa acompanhar o estado por piece e evitar requests duplicados ou lacunas.

request, data e reject

O cliente pede um piece e o Peer responde com data ou reject. Um reject não é necessariamente falha permanente: outro Peer pode fornecer o mesmo piece. É útil manter vários candidatos e limitar outstanding requests por conexão.

Um Peer lento não deveria bloquear a tarefa inteira; pieces restantes podem ser redistribuídos.

Validação é obrigatória

Depois de remontar a Metadata, o hash correspondente deve ser recalculado e comparado à identidade alvo. Um bencode parseável não prova correção. Dados corrompidos, errados ou maliciosos não devem entrar no canonical store.

O sucesso só deve ser registrado após validation completa.

Esboço de implementação

{"msg_type": 0, "piece": 0}          // request
{"msg_type": 1, "piece": 0,
 "total_size": 48321}                // data header, followed by bytes
{"msg_type": 2, "piece": 0}          // reject

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

  • Achar que BEP 9 transfere o .torrent inteiro.
  • Ignorar metadata_size e limites de pieces.
  • Salvar dados parseáveis sem validar hash.
  • Deixar um Peer lento bloquear toda a tarefa.

Artigos relacionados do BT9G Labs

Referências

Próximo artigo: BEP 10 Extension Protocol: como expandir BitTorrent sem quebrar compatibilidade →

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.