DC y el método erróneo
Relay | agosto 20, 2009En esta entrada os voy a hablar de un cliente popular de P2P: el DC, Direct Connect.
Este cliente y sistema se suele usar en las party’s de pc’s (Campus Party, Euskal Party y sucedáneos). El problema radica en la mierda de protocolo que usa.
Se partió de la idea de usar la misma que el Kazaa o Napster en su principio. El usuario comparte lo que quiere, uno mira la lista y decide bajar o copiarse un fichero.
El problema radica en que el fichero solo se asigna para bajarse de un usuario en particular. Teniendo en cuenta que, de los usuarios conectados al servidor, habrá más de 1 que tenga el mismo fichero, no es descabellado pensar que cuando un usuario no tiene slots o no está disponible para bajar, se pueda tirar de otro (en esencia era lo que hacían Napster y Kazaa).
El tema es que DC se ha enfocado a búsquedas de fichero en usuarios, no a la búsqueda de ficheros por servidor. De poco sirve tener el sistema, que es cojonudo en parte, si no podemos tener un hash del fichero para saber si dos ficheros del mismo nombre son el mismo… Eso es lo que le hace falta al Direct Connect, que los ficheros calculen la hash y la envíen al servidor… así se puede tener una relación de quién tiene ese fichero para tener más opciones de descargar. Es más o menos lo que hace el protocolo de eMule al arrancar, genera las hash de los ficheros… luego lo que falla en el eMule es la mierda de protocolo.
Yo lo que propongo es añadir esa función al DC cliente, y que el servidor admita las hash… así se puede ir saltando de un usuario a otro, sin tener que preocuparse. Aunque el tiempo de proceso al principio sería costoso, para generar las hash y todo, luego iría todo más rápido.