Conexión directa (protocolo)

Direct Connect ( DC ) es un protocolo de intercambio de archivos entre pares . Los clientes de Direct Connect se conectan a un concentrador central y pueden descargar archivos directamente entre sí. Advanced Direct Connect puede considerarse un protocolo sucesor.

Los hubs muestran una lista de clientes o usuarios conectados. Los usuarios pueden buscar archivos y descargarlos de otros clientes, así como chatear con otros usuarios.

NeoModus fue fundada como una empresa financiada por el adware "Direct Connect" por Jon Hess en noviembre de 1999, cuando estaba en la escuela secundaria. ^{[ 1 ]}

El primer cliente de terceros se llamaba "DClite", que nunca fue totalmente compatible con las funciones de intercambio de archivos del protocolo. Hess lanzó una nueva versión de Direct Connect, que requería una clave de cifrado simple para iniciar una conexión, lo que impedía el uso de clientes de terceros. La clave de cifrado fue descifrada, y el autor de DClite lanzó una nueva versión compatible con el nuevo software de NeoModus. Tiempo después, DClite se reescribió como Open Direct Connect con el propósito de tener una interfaz de usuario MDI y usar complementos para protocolos de intercambio de archivos (similar a MLDonkey ). Open Direct Connect tampoco era totalmente compatible con las funciones de intercambio de archivos del protocolo, pero una versión para Java sí lo era. Más tarde, otros clientes como DCTC (Direct Connect Text Client) y DC++ se hicieron populares.

El archivo DCDev ^{[ 2 ]} contiene discusiones sobre los cambios de protocolo para el desarrollo de DC en los años 2003–2005.

El protocolo Direct Connect es un protocolo informático basado en texto, en el que los comandos y su información se envían en texto plano, sin cifrado en el software original de NeoModus ( el cifrado está disponible como extensión del protocolo). Los clientes se conectan a un servidor central que actúa como un "hub". Este hub proporciona descubrimiento de contenido y permite a los clientes negociar conexiones directas entre sí para transferir contenido. Dado que este hub central solo gestiona metadatos, no tiene ni de lejos los mismos requisitos de ancho de banda que si también sirviera el contenido en sí; se estima que gestionar 1000 usuarios requeriría aproximadamente 2,5 Mbit/s de ancho de banda. ^{[ 3 ]}

No existe una especificación oficial del protocolo, lo que significa que cada cliente y hub (aparte del cliente y hub NeoModus original) se ha visto obligado a realizar ingeniería inversa para obtener la información. Por lo tanto, cualquier especificación del protocolo a la que haga referencia este artículo probablemente sea inexacta o incompleta. ^{[ 4 ]}

El aspecto cliente-servidor (así como cliente-cliente, donde un cliente actúa como "servidor") del protocolo estipula que el servidor debe responder primero cuando se establece una conexión. Por ejemplo, cuando un cliente se conecta al socket de un concentrador , este último debe responder primero al cliente.

El protocolo carece de una codificación de caracteres predeterminada específica para clientes o concentradores. El cliente y el concentrador originales utilizan la codificación ASCII en lugar de la del sistema operativo . Esto permite la migración a la codificación UTF-8 en software más reciente.

El puerto 411 es el puerto predeterminado para los concentradores (hubs) y el 412 para las conexiones entre clientes. Si alguno de estos puertos ya está en uso, el número de puerto se incrementa hasta encontrar un puerto libre. Por ejemplo, si los puertos 411, 412 y 413 están en uso, se utilizará el puerto 414.

Las direcciones del hub tienen el siguiente formato: dchub://example.com[:411], donde 411 es un puerto opcional.

No existe un sistema de identificación global; en cambio, los usuarios se identifican mediante su apodo en cada centro de la red.

Una solicitud entrante de conexión cliente-cliente no puede vincularse con una conexión real. ^{[ 5 ]}

Un resultado de búsqueda no puede vincularse con una búsqueda en particular. ^{[ 6 ]}

El protocolo permite expulsar o redirigir a un usuario a otro hub. Si se expulsa a un usuario, el hub no está obligado a proporcionarle una razón específica, y no hay restricciones sobre a dónde puede ser redirigido. Sin embargo, si otro cliente con permisos de administrador ordena al hub que expulse al usuario, puede enviar un mensaje de notificación antes de hacerlo. La redirección de un usuario debe ir acompañada de una razón. No existe un equivalente al parámetro HTTP Referer .

Los hubs pueden enviar comandos de usuario a los clientes. Estos comandos son simplemente comandos de protocolo sin procesar y se utilizan principalmente para simplificar una tarea específica. Por ejemplo, el hub no puede enviar un comando de usuario que active el navegador predeterminado para visitar un sitio web. Sin embargo, puede agregar el comando "+rules" (donde "+" indica al hub que se trata de un comando; esto puede variar) para mostrar las reglas del hub.

La parte de comunicación entre pares del protocolo se basa en el concepto de "ranuras" (similar al número de puestos vacantes en una oferta de trabajo). Estas ranuras indican el número de personas autorizadas a descargar archivos de un usuario en un momento dado y son controladas por el cliente.

En las conexiones entre clientes, las partes generan un número aleatorio para determinar quién debe tener permiso para descargar primero, y gana el cliente con el número mayor.

El transporte de descargas y la conexión al hub requieren TCP , mientras que las búsquedas activas utilizan UDP .

Existen dos modos de funcionamiento para los usuarios: activo o pasivo. Los clientes en modo activo pueden descargar desde cualquier otro usuario de la red, mientras que los usuarios en modo pasivo solo pueden descargar desde usuarios activos. En NeoModus Direct Connect, los usuarios en modo pasivo reciben los resultados de búsqueda de otros usuarios en modo pasivo, pero no pueden descargar nada. En DC++ , los usuarios no reciben dichos resultados. En NeoModus Direct Connect, todos los usuarios reciben como máximo cinco resultados de búsqueda por consulta. Si un usuario ha realizado una búsqueda, DC++ responde con diez resultados cuando está en modo activo y cinco cuando está en modo pasivo. Los clientes pasivos reciben los resultados de búsqueda a través del hub, mientras que los clientes activos los reciben directamente.

Los delimitadores de protocolo son "$", "|" y U+0020 ESPACIO  . El protocolo tiene una secuencia de escape para estos (y algunos otros) y la mayoría del software los usa correctamente en la secuencia de inicio de sesión (de bloqueo a clave). Por alguna razón, los desarrolladores de DC++ ignoraron esta secuencia de escape y usan el equivalente HTML si estos caracteres deben ser visibles para el usuario.

Persiste el interés en características como las clasificaciones y los paquetes de idiomas. Los autores de DC++ también propusieron un reemplazo completo del protocolo Direct Connect llamado ADC, o extraoficialmente, Advanced Direct Connect. ADC utiliza la misma topología de red , conceptos y terminología que el protocolo original. ^{[ 7 ]}

Un ejemplo de una función añadida al protocolo, en comparación con el protocolo original, es la difusión del hash Tiger-Tree de archivos compartidos (TTH). Entre las ventajas de esto se incluyen la verificación de que un archivo se ha descargado correctamente y la capacidad de encontrar archivos independientemente de su nombre.

Dado que el protocolo permite que los hubs redirijan a los usuarios a otros hubs , los hubs maliciosos han redirigido a los usuarios a lugares distintos de los hubs Direct Connect reales, provocando así un ataque de denegación de servicio distribuido ( DDoS ). Los hubs pueden alterar la IP en las conexiones entre clientes, apuntando a una posible víctima. ^{[ 8 ] [ 9 ] [ 10 ]}

La vulnerabilidad CTM surgió entre 2006 y 2007, periodo durante el cual toda la red Direct Connect sufrió ataques DDoS. ^{[ 11 ] [ 12 ]} Esta situación impulsó a los desarrolladores a tomarse más en serio los problemas de seguridad. ^{[ 13 ]}

A partir de febrero de 2009, ^{[ 14 ] [ 15 ] [ 16 ] [ 17 ] [ 12 ]} se propuso una extensión para clientes con el fin de que la parte atacada pudiera averiguar el hub que enviaba a los usuarios conectados.

La Direct Connect Network Foundation (DCNF) es una organización sin fines de lucro registrada en Suecia que tiene como objetivo mejorar la red DC mediante la mejora del software, los protocolos y otros servicios en la red. ^{[ 18 ]}

La DCNF mantiene una lista de artículos, documentos y más documentación relacionada con DC. ^{[ 19 ]}

• Comparación del software Direct Connect

• Wiki del protocolo NMDC (Espejo) Archivado el 8 de abril de 2022 en Wayback Machine
• Documento de protocolo NMDC
• Protocolo NMDC