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 incluyen una lista de clientes o usuarios conectados a ellos. 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 mientras estaba en la escuela secundaria. [1]
El primer cliente de terceros se llamó "DClite", que nunca admitió por completo los aspectos 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 bloqueaba a los clientes de terceros. La clave de cifrado fue descifrada y el autor de DClite lanzó una nueva versión de DClite compatible con el nuevo software de NeoModus. Algún 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 tenía soporte completo para todos los aspectos de intercambio de archivos del protocolo, pero un puerto para Java , sin embargo, sí lo tenía. Más tarde, otros clientes como DCTC (Direct Connect Text Client) y DC++ se hicieron populares.
El archivo DCDev [2] contiene debates 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 claro, sin cifrado en el software NeoModus original ( el cifrado está disponible como una extensión del protocolo). Los clientes se conectan a un servidor central que actúa como un "centro". Este centro proporciona descubrimiento de contenido y permite a los clientes negociar conexiones directas entre sí para transferir contenido. Dado que este centro central solo se ocupa de metadatos, no tiene ni de lejos los mismos requisitos de ancho de banda que si también hubiera estado sirviendo el contenido en sí; una estimación muestra que manejar 1000 usuarios requeriría alrededor de 2,5 mbit/s de ancho de banda. [3]
No existe una especificación oficial del protocolo, lo que significa que cada cliente y concentrador (además del cliente y concentrador NeoModus original) se vio obligado a aplicar ingeniería inversa a la información. Por lo tanto, cualquier especificación de protocolo a la que se haga referencia en 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 responde primero cuando se establece una conexión. Por ejemplo, cuando un cliente se conecta al socket de un concentrador , el concentrador es el primero en responder 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 nuevo.
El puerto 411 es el puerto predeterminado para los concentradores 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 que se encuentra un puerto libre para usar. Por ejemplo, si se utilizan los puertos 411, 412 y 413, se utilizará el puerto 414.
Las direcciones del concentrador tienen el siguiente formato: dchub://example.com[:411], donde 411 es un puerto opcional.
No existe un esquema de identificación global; en cambio, los usuarios se identifican con su apodo en cada centro.
Una solicitud entrante para una conexión cliente-cliente no se puede vincular con una conexión real. [5]
Un resultado de búsqueda no se puede vincular con una búsqueda en particular. [6]
El protocolo admite la posibilidad de expulsar o mover (redirigir) a un usuario a otro concentrador. Si se expulsa a un usuario, el concentrador no está obligado a proporcionarle un motivo específico y no hay ninguna restricción sobre el lugar al que se puede redirigir a un usuario. Sin embargo, si otro cliente con autoridad le ordena al concentrador que expulse, ese cliente puede enviar un mensaje de notificación antes de hacerlo. La redirección de un usuario debe ir acompañada de un motivo. No existe un equivalente de referencia HTTP .
Los concentradores pueden enviar comandos de usuario a los clientes. Estos comandos son solo comandos de protocolo sin formato y se utilizan principalmente para simplificar una tarea en particular. Por ejemplo, el concentrador no puede enviar un comando de usuario que haga que el navegador predeterminado visite un sitio web. Sin embargo, puede agregar el comando "+rules" (donde "+" indica al concentrador que es un comando; esto puede variar) para mostrar las reglas del concentrador.
La parte peer-to-peer del protocolo se basa en un concepto de "slots" (similar al número de puestos vacantes para un trabajo). Estos slots indican el número de personas que pueden descargar datos de un usuario en un momento dado y están controlados por el cliente.
En las conexiones de cliente a cliente, las partes generan un número aleatorio para ver a quién se le debe permitir descargar primero, y el cliente con el mayor número gana.
El transporte de descargas y la conexión al concentrador requieren TCP , mientras que las búsquedas activas utilizan UDP .
Hay dos tipos de modos en los que puede estar un usuario: modo "activo" o "pasivo". Los clientes que usan el modo activo pueden descargar desde cualquier otra persona en la red, mientras que los clientes que usan 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 el usuario no podrá descargar nada. En DC++ , los usuarios no recibirán esos resultados de búsqueda. En NeoModus Direct Connect, a todos los usuarios se les enviarán como máximo cinco resultados de búsqueda por consulta. Si un usuario ha realizado una búsqueda, DC++ responderá con diez resultados de búsqueda cuando el usuario esté en modo activo y cinco cuando esté en modo pasivo. Los clientes pasivos recibirán los resultados de búsqueda a través del concentrador, mientras que los clientes activos recibirán los resultados directamente.
Los delimitadores de protocolo son "$", "|" y U+0020 SPACE . El protocolo tiene para ellos (y algunos otros) una secuencia de escape y la mayoría del software los usa correctamente en la secuencia de inicio de sesión (bloqueo a clave). Por alguna razón, los desarrolladores de DC++ ignoraron esa secuencia de escape y usaron el equivalente en HTML si el usuario debe ver estos caracteres.
Existe un interés continuo en funciones como clasificaciones y 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 característica añadida al protocolo, en comparación con el protocolo original, es la difusión del algoritmo Tiger-Tree Hashing de archivos compartidos (TTH). Las ventajas de esto incluyen la verificación de que un archivo se descarga correctamente y la capacidad de encontrar archivos independientemente de sus nombres.
Como el protocolo permite que los concentradores redirijan a los usuarios a otros concentradores , los concentradores maliciosos han redirigido a los usuarios a lugares distintos de los concentradores de conexión directa reales, lo que provoca un ataque de denegación de servicio distribuido . Los concentradores pueden alterar la IP en las conexiones de cliente a cliente, lo que apunta a una víctima potencial. [8] [9] [10]
El exploit CTM apareció entre 2006 y 2007, período durante el cual toda la red Direct Connect sufrió ataques DDoS. [11] [12] La situación impulsó a los desarrolladores a tomar 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 concentrador que envía a los usuarios que se conectan.
La Direct Connect Network Foundation (DCNF) es una organización sin fines de lucro registrada en Suecia que tiene como objetivo mejorar la red de CC mediante la mejora del software, los protocolos y otros servicios en la red. [18]
El DCNF mantiene una lista de artículos, documentos y más documentación relacionada con DC. [19]