BT9G LABS / DHT em profundidade #11

BEP 10 Extension Protocol: como expandir BitTorrent sem quebrar compatibilidade

Extended handshake, message IDs dinâmicos e o papel do BEP 10 como base para ut_metadata e PEX.

BT9G LabsPublicado 3 min de leitura

BT9G Labs / DHT Deep Dive #11. Entenda como capacidades são negociadas por conexão sem alterar o Peer Wire Protocol básico para cada novo recurso.

BEP 10 Extension Protocol: como expandir BitTorrent sem quebrar compatibilidade

Resumo rápido

  • Tema: BEP 10 Extension Protocol: como expandir BitTorrent sem quebrar compatibilidade
  • Palavras-chave: BEP 10, Extension Protocol, extended handshake, ut_metadata, 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 problema de compatibilidade

Um protocolo P2P de longa vida precisa adicionar recursos sem quebrar clientes antigos. BEP 10 usa reserved bits no handshake base para indicar suporte e depois troca um extended handshake com as capacidades concretas.

Assim extensões podem evoluir sem grandes mudanças no protocolo base.

Extended handshake e IDs dinâmicos

O dicionário m mapeia nomes de extensões para message IDs escolhidos pelo Peer naquela conexão. Também pode trazer versão do cliente, porta ou metadata_size. O ID numérico de ut_metadata não é uma constante global e precisa ser lido por conexão.

Hardcode desse número é um erro clássico.

Por que isso importa ao indexador

Um indexador baseado em Magnet costuma depender de BEP 9 e descobre ut_metadata por BEP 10. Medir separadamente connection success, basic handshake, suporte BEP 10, suporte ut_metadata e Metadata complete mostra exatamente onde a conversão está sendo perdida.

Unsupported extension e network failure devem ser categorias distintas.

Esboço de implementação

Base handshake
  reserved bit says: extension protocol supported
        |
        v
Extended handshake
  m = { "ut_metadata": 3, "ut_pex": 1 }
  metadata_size = 48321
        |
        v
Extended message 3 now means ut_metadata for this connection

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

  • Assumir que todo Peer suporta BEP 10.
  • Usar um message ID fixo em todas as conexões.
  • Enviar ut_metadata antes do extended handshake.
  • Misturar unsupported extension e network failure.

Artigos relacionados do BT9G Labs

Referências

Próximo artigo: Tracker vs DHT vs PEX: comparação de três mecanismos de Peer Discovery →

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.