Direct Connect ( DC ) es un protocolo de intercambio de archivos de igual a igual . 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 concentradores cuentan con 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.
Historia
NeoModus se inició como una empresa financiada por el software publicitario "Direct Connect" de Jon Hess en noviembre de 1999 mientras estaba en la escuela secundaria. [1]
El primer cliente de terceros se llamó "DClite", que nunca admitió completamente los aspectos de intercambio de archivos del protocolo. Hess lanzó una nueva versión de Direct Connect, que requiere una clave de cifrado simple para iniciar una conexión, bloqueando 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 del protocolo para compartir archivos, pero sí un puerto para Java . 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.
Protocolo
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 sin cifrar , sin cifrado en el software NeoModus original (el cifrado está disponible como una extensión del protocolo). A medida que los clientes se conectan a una fuente central de distribución (el concentrador) de información, el concentrador requiere una cantidad sustancial de ancho de banda de carga disponible. [3]
No existe una especificación oficial del protocolo, lo que significa que todos los clientes y concentradores (además del cliente y concentrador NeoModus originales) se han visto obligados a aplicar ingeniería inversa a la información. Como tal, cualquier especificación de protocolo a la que este artículo pueda hacer referencia probablemente sea inexacta y / o incompleta. [4]
El aspecto cliente-servidor (así como cliente-cliente, donde un cliente actúa como "servidor") del protocolo estipula que el servidor responderá primero cuando se establezca una conexión. Por ejemplo, cuando un cliente se conecta al zócalo de un concentrador , el concentrador es el primero en responder al cliente.
El protocolo carece de una codificación de caracteres predeterminada especificada para clientes o concentradores. El cliente y el concentrador originales utilizan codificación ASCII en lugar de la del sistema operativo . Esto permite la migración a la codificación UTF-8 en un software más nuevo.
El puerto 411 es el puerto predeterminado para concentradores y el 412 para conexiones de cliente a cliente. Si alguno de estos puertos ya está en uso, el número de puerto se incrementa hasta que se encuentre el número de un puerto libre para su uso. Por ejemplo, si se utilizan 411, 412 y 413, se utilizará el puerto 414.
Las direcciones de concentrador tienen el siguiente formato: dchub: //example.com [: 411], donde 411 es un puerto opcional.
No existe un esquema de identificación global; en su lugar, los usuarios se identifican con su apodo de concentrador a concentrador.
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 capacidad de expulsar o mover (redirigir) a un usuario a otro concentrador. Si se expulsa a un usuario, no se requiere que el concentrador le dé a ese usuario una razón específica y no hay restricciones sobre a dónde se puede redirigir a un usuario. Sin embargo, si otro cliente en el poder le indica al concentrador que se active, 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 hay 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 active el navegador predeterminado para visitar un sitio web. Sin embargo, puede agregar el comando "+ reglas" (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 "espacios" (similar al número de puestos vacantes para un trabajo). Estos espacios denotan la cantidad de personas que pueden descargar de un usuario en un momento dado y son controladas 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 usan UDP .
Hay dos tipos de modos en los que un usuario puede estar: 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 el modo pasivo solo pueden descargar de los usuarios activos. En NeoModus Direct Connect , los usuarios del modo pasivo reciben los resultados de búsqueda de otros usuarios del 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, todos los usuarios recibirán un máximo de cinco resultados de búsqueda por consulta. Si un usuario ha buscado, DC ++ responderá con diez resultados de búsqueda cuando el usuario esté en modo activo y cinco cuando el usuario esté en modo pasivo. A los clientes pasivos se les enviarán los resultados de la 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 tecla). Por alguna razón, los desarrolladores de DC ++ ignoraron la secuencia de escape y usan HTML equivalente si el usuario va a ver estos caracteres.
Existe un interés continuo en características como calificaciones y paquetes de idiomas. Sin embargo, los autores de DC ++ han estado trabajando activamente en un reemplazo completo del protocolo Direct Connect llamado Advanced Direct Connect .
Un ejemplo de una característica agregada al protocolo, en comparación con el protocolo original, es la transmisión de Tiger-Tree Hashing de archivos compartidos (TTH). Las ventajas de esto incluyen verificar que un archivo se descargue correctamente y la capacidad de encontrar archivos independientemente de sus nombres.
Hublists
Nombre | NMDC | ADC | Registro | Detección de CTM | Detección de troyanos | Activo | Unicode |
---|---|---|---|---|---|---|---|
ufo-modus.com | sí | sí | Regserver | sí | sí | sí | sí |
dchublist.org | sí | sí | Basado en web / Regserver | sí | sí | sí | sí |
tankafett.biz | sí | No | Basado en web / Regserver | sí | sí | sí | |
te-home.net/ | sí | No | Basado en web | sí | No | sí | |
hublist.org.nz | sí | No | Basado en web | Desconocido | No | sí | |
dchublist.ru | sí | No | Desconocido | Desconocido | No | sí | |
dchublist.biz/ | sí | No | Basado en web | sí | No | sí |
Direct Connect utilizado para ataques DDoS
Dado que el protocolo permite que los concentradores redirijan a los usuarios a otros concentradores , los concentradores maliciosos han redirigido a los usuarios a lugares distintos a los concentradores de Direct Connect reales, lo que provoca un ataque de denegación de servicio distribuido . Los hubs pueden alterar la IP en las conexiones de cliente a cliente, apuntando a una víctima potencial. [7] [8] [9]
El CTM Exploit apareció en 2006-2007, período durante el cual toda la red Direct Connect sufrió ataques DDoS. [10] [11] La situación llevó a los desarrolladores a tomar los problemas de seguridad más en serio. [12]
En febrero de 2009, [13] [14] [15] [16] [11] se propuso una extensión para clientes con el fin de que la parte atacada averiguara el hub que envía a los usuarios que se conectan.
Fundación de red de conexión directa
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 mejorando el software, los protocolos y otros servicios en la red. [17]
Artículos y ponencias
El DCNF mantiene una lista de artículos, trabajos y más documentación relacionada con DC. [18]
Ver también
- Comparación del software Direct Connect
- Conexión directa avanzada
Referencias
- ^ Annalee Newitz (julio de 2001). "Compartir los datos" . Metro, periódico semanal de Silicon Valley . Metro Publishing Inc . Consultado el 16 de octubre de 2006 .
- ^ El archivo DCDev Archivado el 20 de diciembre de 2016 en la Wayback Machine.
- ^ Fredrik Ullner (abril de 2007). "Estimaciones de ancho de banda y comando en NMDC" . DC ++: Solo estos chicos, ¿sabes? . Consultado el 27 de julio de 2007 .
- ^ "Protocolo NMDC" . Nmdc.sourceforge.net . Consultado el 4 de diciembre de 2016 .
- ^ "Tokens CTM en ADC (o por qué el protocolo NMDC es terrible, parte 2)" . DC ++: Solo estos chicos, ¿sabes? Agosto de 2007 . Consultado el 7 de octubre de 2007 .
- ^ Todd Pederzani (junio de 2006). "Filtrado de Redux" . DC ++: Solo estos chicos, ¿sabes? . Consultado el 31 de agosto de 2007 .
- ^ Paul Sop (mayo de 2007). "Alerta de ataque de denegación de servicio distribuida de Prolexic" . Prolexic Technologies Inc . Prolexic Technologies Inc. Archivado desde el original el 3 de agosto de 2007 . Consultado el 22 de agosto de 2007 .
- ^ Robert Lemos (mayo de 2007). "Redes peer-to-peer cooptadas para ataques DOS" . SecurityFocus . Consultado el 22 de agosto de 2007 .
- ^ Fredrik Ullner (mayo de 2007). "Negar ataques distribuidos" . DC ++: Solo estos chicos, ¿sabes? . Consultado el 22 de agosto de 2007 .
- ^ Ullner, Frederik (17 de enero de 2008). "Cobertura de prensa sobre el uso de DC como herramienta DDoS" . DC ++: Solo estos chicos, ¿sabes?
- ^ a b Fredrik Ullner (20 de julio de 2011). "Respuesta perdida en relación con el uso de DC como herramienta DDoS" . DC ++: Solo estos chicos, ¿sabes? . Consultado el 20 de julio de 2011 .
- ^ Furtunã, Adrian (julio de 2008). "Ataques DC ++ y DDoS" (PDF) .
- ^ Jan Vidar Krey (febrero de 2009). "Extensión de referencia" . Página de DC ++ Launchpad . Consultado el 11 de febrero de 2009 .
- ^ Jan Vidar Krey (febrero de 2009). "Extensión de referencia en la wiki de ADCPortal" . ADCPortal.com. Archivado desde el original el 7 de julio de 2011 . Consultado el 11 de febrero de 2009 .
- ^ Eugen Hristev (febrero de 2009). "DC ++ señalando los corruptos" . DC ++: Solo estos chicos, ¿sabes? . Consultado el 11 de febrero de 2009 .
- ^ Brindis (enero de 2009). "Revisión de CTM y los errores del pasado" . ADCPortal. Archivado desde el original el 7 de julio de 2011 . Consultado el 27 de enero de 2009 .
- ^ "Copia archivada" . Archivado desde el original el 25 de enero de 2016 . Consultado el 7 de enero de 2016 .CS1 maint: copia archivada como título ( enlace )
- ^ Direct Connect Network Foundation: documentos y recursos archivados el 20 de diciembre de 2016 en la Wayback Machine.
enlaces externos
- Wiki del protocolo NMDC (espejo)
- Documento de protocolo NMDC [ enlace muerto permanente ]
- Protocolo NMDC