Direct Connect
# Direct Connect

Direct Connect es una aplicación peer-to-peer escrita por Jon Hess de NeoModus. Tras su creación, han ido apareciendo otros clientes que implementan el protocolo de Direct Connect. Los clientes de Direct Connect conectan a un hub central.

El protocolo está basado en FTP. Originariamente fue un protocolo cerrado (privativo), luego se consiguió implementar como software libre, existiendo diversos clientes para esta red, como son MlDonkey, DC++ (implementado en C++ y primer cliente Software Libre para Direct Connect) y oDC (basado en DC++) para Windows o ShakesPeer para Mac OS X.

Su funcionamiento se basa en servidores centrales llamados hubs. Este hub contiene un listado de todos los clientes que se han conectado a él, y todos los archivos que están compartiendo. Al hacer una búsqueda en el hub, este devuelve una referencia a todos los archivos que tienen relación con el buscado y qué clientes lo poseen, y a continuación el cliente solicitante descarga el archivo en cuestión mediante FTP directamente desde el cliente que posee el archivo buscado, desvinculándose por completo el ordenador que hace de hub (en este sentido, se puede interpretar el hub como un directorio de archivos que solamente indica quién tiene qué). No hay excesivos problemas con el ancho de banda debido a que cuando se registra una máquina en el hub se identifican todos los archivos que comparte con su hash, pudiéndose buscar otros archivos con el mismo hash pero distinto nombre por la razón que sea que según la teoría del hasheo son el mismo archivo.

Aunque está pensado para funcionar por hubs de internet, es posible abrir hubs que funcione en una Red local LAN y así administrar sockets abiertos (número de descargas concurrentes), cantidad de gigabytes compartidos, baneo de contenidos (por ejemplo pornografía)... Esto permite facilitar mínimos de calidad en las distintas subredes que se crean con cada hub, evitando los lammers.

## Funcionamiento

Los clientes se conectan al servidor, al cual se le denomina HUB. Es el encargado de gestionar las conexiones entre clientes, como si de un servidor de la red ed2k se tratase. El cliente, una vez conectado al servidor, tiene posibilidad de comunicarse con otros usuarios conectados, hacer búsquedas y, por supuesto, compartir ficheros. Por lo general los HUB tienen temáticas muy bien definidas como pueden ser estilos de música concretos, cine de acción, de terror, anime, etc.. Un usuario, para poder conectarse, ha de cumplir 2 condiciones:

* Compartir la mínima cantidad de material que el servidor le exija: si no cumple dicha condición al conectarse el HUB le echará y le pedirá que comparta, por ejemplo, 10 GB.
* Tener un mínimo de SLOT's disponibles: para entender esto necesitamos saber qué es un SLOT, que no es más que la capacidad numérica de conexiones simultáneas que se aceptan desde el computador; si el HUB nos exige tener un mínimo de 10 SLOT's, significa que, una vez estemos conectados, podrán conectarse a nosotros un máximo de diez (10) usuarios a la vez (al mismo tiempo).

Estos métodos, que a algunos les parecerán abusivos, son de lo más común y se usan para evitar leechers (usuarios que adquieren algo de los demás pero no comparten).

Cuando encontremos algo interesante y procedamos a descargarlo se creará una conexión entre ambos clientes. Si el que comparte el fichero se cae, la mayoría de clientes DC permiten buscar otras fuentes para continuar descargando.

Es muy común en parties grandes como la Riojaparty, Euskal, Campus Party, e incluso en otras más pequeñas como la Enredada, la Navarparty la 802.Party la Gumiparty o la Hortanet. No se precisa poseer un ordenador de mucha potencia para manejar 4200 clientes simultáneamente sin verse afectado su rendimiento.

