Hispanopedia WikiMainline DHT es el nombre que recibe la tabla hash distribuida (DHT) basada en Kademlia que utilizan los clientes de BitTorrent para encontrar pares a través del protocolo BitTorrent . La idea de usar una DHT para el seguimiento distribuido en BitTorrent se implementó por primera vez [ 1 ] [ 2 ] en Azureus 2.3.0.0 (ahora conocido como Vuze ) en mayo de 2005, desde donde ganó una popularidad significativa. De forma no relacionada, pero casi al mismo tiempo, BitTorrent, Inc. lanzó una DHT similar en su cliente llamada Mainline DHT, popularizando así el uso del seguimiento distribuido en el protocolo BitTorrent. Las mediciones mostraron que para 2013, el número de usuarios concurrentes de Mainline DHT era de 16 millones a 28 millones, con cambios intradía de al menos 10 millones. [ 3 ]
Descripción
Mainline DHT se basa en el popular diseño de Kademlia DHT. [ 4 ] Antes de usar una DHT para distribuir pares, los rastreadores eran el único método para encontrar pares. [ 5 ] La característica clave de usar la DHT en lugar de los rastreadores es que el enfoque descentralizado favorece la naturaleza del protocolo BitTorrent. La DHT funciona distribuyendo listas de pares identificados por el hash SHA-1 del torrent.
Cada cliente selecciona aleatoriamente un ID de nodo de 160 bits, y la distancia entre nodos se calcula mediante la operación XOR de sus ID. La DHT principal utiliza k-cubetas para rastrear los nodos conocidos.
Para descargar un archivo, un cliente primero consulta sus k-buckets para encontrar los nodos más cercanos al torrent info_hash. Se conecta a estos nodos para encontrar pares. Si encuentra pares, el cliente descarga el archivo desde múltiples fuentes, de forma similar al protocolo BitTorrent estándar. [ 5 ]
Operación
El hash SHA-1 de un torrent, el infohash , es sinónimo de una clave Kademlia, que se utiliza para encontrar pares (valores) en la red superpuesta . Para encontrar pares en un enjambre, un nodo envía una consulta get_peers con el infohash como clave (equivalente a un FIND_VALUE de Kademlia ) a los nodos conocidos más cercanos (con respecto a la distancia de la clave). Al igual que en Kademlia, si el nodo no devuelve el valor (pares), persiste en una operación iterativa. Sin embargo, una vez agotada la búsqueda, el cliente también inserta la información de contacto del par para sí mismo en los nodos que responden con los ID más cercanos al infohash del torrent.
Simbólico
Los nodos utilizan una medida adicional, conocida como token, para evitar que otros registren otros hosts para torrents. El valor devuelto por una consulta de pares incluye este valor opaco. Para que un nodo anuncie que su par controlador está descargando un torrent, debe presentar el token recibido del mismo nodo consultado en una consulta reciente de pares. Cuando un nodo intenta "anunciar" un torrent, el nodo consultado verifica el token con la dirección IP del nodo que realiza la consulta.
Mainline DHT utiliza el hash SHA-1 de la dirección IP concatenado con un secreto que cambia cada cinco minutos para generar un valor de token. Se aceptan tokens con una antigüedad máxima de diez minutos.
KRPC
Un nodo en la DHT principal consta de una combinación de IP y puerto. Los nodos se comunican mediante un protocolo RPC llamado KRPC . KRPC es un protocolo simple que consiste en que los nodos envían mensajes (consultas, respuestas y errores) que contienen diccionarios codificados en Ben a través de UDP .
Un mensaje KRPC es un diccionario único con dos claves comunes a todos los mensajes y claves adicionales que dependen del tipo de mensaje. Cada mensaje tiene una clave "t" con un valor de cadena que representa un ID de transacción. Este ID de transacción lo genera el nodo que realiza la consulta y se incluye en la respuesta, por lo que las respuestas pueden correlacionarse con múltiples consultas al mismo nodo. El ID de transacción debe codificarse como una cadena corta de números binarios; normalmente, dos octetos son suficientes, ya que cubren 2^16 consultas pendientes. La otra clave contenida en cada mensaje KRPC es "y", con un valor de un solo carácter que describe el tipo de mensaje. El valor de la clave "y" puede ser "q" para consulta, "r" para respuesta o "e" para error.
Consultas
Las consultas, o diccionarios de mensajes KRPC con un valor "y" igual a "q", contienen dos claves adicionales: "q" y "a". La clave "q" tiene un valor de cadena que contiene el nombre del método de la consulta. La clave "a" tiene un valor de diccionario que contiene los argumentos con nombre de la consulta.
Respuestas
Las respuestas, o diccionarios de mensajes KRPC con un valor "r" en la variable "y", contienen una clave adicional "r". El valor "r" es un diccionario que contiene valores de retorno con nombre. Los mensajes de respuesta se envían al completarse con éxito una consulta.
Errores
Los errores, o diccionarios de mensajes KRPC con un valor "e" en la variable "y", contienen una clave adicional "e". El valor de "e" es una lista. El primer elemento es un número entero que representa el código de error. El segundo elemento es una cadena que contiene el mensaje de error. Se envían errores cuando no se puede completar una consulta.
Tabla de enrutamiento
Los buckets tienen una estructura diferente a la de Kademlia. En lugar de una lista de 160 buckets, BitTorrent comienza con un solo bucket. Cuando un bucket se llena, pueden ocurrir dos cosas:
- El cubo está partido.
- Se realiza un ping a los nodos antiguos (como en Kademlia).
La división es una operación que solo se produce si nuestro ID de nodo se encuentra dentro del rango del cubo. El cubo que se divide se reemplaza por dos nuevos cubos, cada uno con la mitad del rango del cubo anterior, y los nodos del cubo anterior se distribuyen entre los dos nuevos.
Esta implementación de cubetas tiene dos ventajas:
- Se utiliza menos memoria para una tabla de enrutamiento con menos de 160 cubetas.
- Al buscar en los depósitos, no es necesario recuperar nodos adicionales de los depósitos adyacentes porque se garantiza que hay suficientes en el depósito actual.
Implementaciones
Mainline DHT se incluyó por primera vez en la versión 4.2.0 del software BitTorrent (noviembre de 2005). Desde entonces, ha sido implementado por varios otros clientes:
Referencias
- ↑ Jones, Ben (7 de junio de 2015). "El DHT de BitTorrent cumple 10 años" . TorrentFreak . Archivado del original el 11 de junio de 2015. Recuperado el 5 de julio de 2015 .
- ↑ "Registro de cambios de Vuze" . Azureus.sourceforge.net. Archivado del original el 1 de diciembre de 2006. Consultado el 15 de julio de 2012 .
- ↑ Wang, Liang; Kangasharju, Jussi (2013). "Medición de sistemas distribuidos a gran escala: caso de BitTorrent Mainline DHT" (PDF) . IEEE Peer-to-Peer . Archivado (PDF) del original el 12 de mayo de 2014. Recuperado el 26 de octubre de 2013 .
- ↑ Loewenstern, Andrew; Norberg, Arvid (22 de marzo de 2013). "Protocolo DHT" . BitTorrent.org . Archivado del original el 20 de mayo de 2015. Consultado el 26 de noviembre de 2021 .
- 1 2 Xinxing, Zhang; Zhihong, Tian; Luchen, Zhang (16 de junio de 2016). "Estudio de medición en DHT de línea principal y enlace magnético". 2016 IEEE First International Conference on Data Science in Cyberspace (DSC) . pp. 11–19 . doi : 10.1109/DSC.2016.106 . ISBN 978-1-5090-1192-6.
- ↑ "Acerca de – Diluvio" . Archivado del original el 10 de febrero de 2011. Consultado el 29 de junio de 2014 .
Enlaces externos
- Especificación oficial y extensiones para la compatibilidad con IPv6.
- Clientes de BitTorrent