BT9G LABS / DHT a fondo #11
BEP 10 Extension Protocol: ampliar BitTorrent sin romper compatibilidad
Extended handshake, message IDs dinámicos y por qué BEP 10 es la base de extensiones como ut_metadata y PEX.
BT9G Labs / DHT Deep Dive #11. Cómo BitTorrent negocia capacidades por conexión sin obligar a modificar el Peer Wire Protocol básico para cada función nueva.
Resumen rápido
- Tema: BEP 10 Extension Protocol: ampliar BitTorrent sin romper compatibilidad
- Palabras clave: BEP 10, Extension Protocol, extended handshake, ut_metadata, BitTorrent
- 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
El problema de compatibilidad
Un protocolo P2P de larga vida debe añadir funciones sin romper clientes antiguos. BEP 10 utiliza reserved bits en el handshake base para indicar soporte y después intercambia un extended handshake con las capacidades reales.
Así las extensiones pueden evolucionar de forma independiente del protocolo base.
Extended handshake e IDs dinámicos
El diccionario m relaciona nombres de extensiones con message IDs elegidos por el Peer para esa conexión. También puede incluir versión de cliente, puerto o metadata_size. El ID numérico de ut_metadata no es una constante global y debe guardarse por conexión.
Hardcodearlo es un error común en crawlers caseros.
Por qué importa a un indexador
Un indexador basado en Magnet suele necesitar BEP 9, y descubre ut_metadata mediante BEP 10. Conviene medir por separado connection success, BitTorrent handshake, soporte BEP 10, soporte ut_metadata y Metadata complete.
Así se identifica exactamente dónde cae la tasa de conversión.
Esquema de implementación
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 connectionNotas 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
- Suponer que todo Peer soporta BEP 10.
- Usar un message ID fijo para todas las conexiones.
- Enviar
ut_metadataantes del extended handshake. - Mezclar unsupported extension con network failure.
Artículos relacionados de BT9G Labs
- De Magnet Link a Metadata: flujo completo de Peer Discovery y BEP 9/10
- BEP 9 ut_metadata explicado: obtener Torrent Metadata desde Peer
- Tracker vs DHT vs PEX: comparación de tres mecanismos de Peer Discovery en BitTorrent
- Seeders y Leechers: qué significan los números y cómo se miden
Referencias
- BEP 10 - Extension Protocol
- BEP 9 - Extension for Peers to Send Metadata Files
- BEP 11 - Peer Exchange (PEX)
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.