BT9G LABS / DHT a fondo #09

De Magnet Link a Metadata: flujo completo de Peer Discovery y BEP 9/10

Sigue un Magnet desde su InfoHash hasta DHT, conexión con Peer, negociación BEP 10 y recuperación de Metadata por BEP 9.

BT9G LabsPublicado 3 min de lectura

BT9G Labs / DHT Deep Dive #09. Cómo una URI centrada en un hash termina produciendo nombres de archivos, tamaños y Metadata validada.

De Magnet Link a Metadata: flujo completo de Peer Discovery y BEP 9/10

Resumen rápido

  • Tema: De Magnet Link a Metadata: flujo completo de Peer Discovery y BEP 9/10
  • Palabras clave: Magnet link, Torrent Metadata, BEP 9, BEP 10, InfoHash
  • 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

Un Magnet está incompleto por diseño

La parte esencial de una Magnet URI suele ser xt=urn:btih:... u otra identidad de contenido. Puede incluir display name o Tracker, pero normalmente no contiene el info dictionary completo. Por tanto no permite conocer de forma fiable la lista de archivos o el tamaño total.

La idea es iniciar discovery solo con la identidad y recuperar los datos faltantes después.

Primero hacen falta Peer candidates

El cliente obtiene endpoints mediante DHT, Tracker u otras fuentes, se conecta y verifica el InfoHash en el BitTorrent handshake. Muchos endpoints ya estarán offline, así que un scheduler real prueba varios candidatos.

get_peers proporciona candidatos; no transfiere Metadata.

BEP 10 → BEP 9 → validación

El extended handshake indica si existe ut_metadata, cuál es su message ID local y, a veces, metadata_size. BEP 9 permite pedir los Metadata pieces. Tras reunirlos, el cliente debe recomponer los bytes y validar la identidad esperada.

Solo el resultado validado debería entrar en canonical storage y en el índice de búsqueda.

Esquema de implementación

magnet(infohash)
   -> discover peers
   -> BitTorrent handshake
   -> BEP 10 extended handshake
   -> ut_metadata requests
   -> assemble info dictionary
   -> hash(info dictionary) == expected infohash ?
   -> parse and index

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

  • Esperar una lista completa de archivos dentro del Magnet.
  • Tratar get_peers como API de Metadata.
  • Fijar un ID global para ut_metadata.
  • Indexar Metadata sin validar el hash.

Artículos relacionados de BT9G Labs

Referencias

Siguiente artículo: BEP 9 ut_metadata explicado: obtener Torrent Metadata desde Peer →

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.