Ars Technica tiene un artículo sobre el SET (Similarity-Enhanced Transfer) un nuevo método para optimizar las búsquedas y descargas en redes P2P.
El paper sale de la Carnegie Mellon University e Intel; y dicen que pueden mejorar las descargas (según Ars en un 70%, según otros en un 200% en el “mundo real”) con una lógica bastante simple; de acuerdo al archivo que estás descargando SET buscaría fragmentos similares en otros archivos dentro de la red P2P, si los encuentra, esto indicaría que, pese a estar en archivos diferentes corresponden al mismo “objeto” (siendo el objeto, una película, una canción o cualquier archivo)… esto implica que habría más fuentes de donde descargar el objeto y, por lo tanto, mayor velocidad de descarga final.
La realidad es que muchas veces hay una misma película con diferentes nombres o con el segmento de audio en otro idioma; lo que hace este sistema es analizar los archivos similares, descubrir cuales son idénticos o complementarios, y bajarlos en paralelo para luego unirlos en tu PC.
Sinceramente, no tengo idea si es factible en una implementación a gran escala porque más allá de las posibilidades de “similarities” falsas que podrían poner la RIAA y otros; existe el problema de descargar cosas equivocadas corrompiendo el archivo final y, supongo, algun que otro problema.. pero, repito, la idea me suena genial.
7 respuestas en “SET: más velocidad para P2P”
http://www.error500.net/set-optimizacion-p2p…
…
Calculo que también podría buscar similitudes con fragmentos que tengamos en nuestro disco y evitar descargarlos nuevamente, no ?
Rodrigo… eso es buena idea… no estaríamos atados a un tracker solo :)
Pero es que yo pensé que eso era así. Entonces que quiere decir mi Limewire cuando dice Descargando de 6 computadoras?
Es que es así! no entiendo donde está la “novedad”, por ejemplo, el e-mule, famoso por ir mas lento que una tortuga, baja pequeños fragmentos, la red kad que ayuda a emule también, etc.
lo que me parece que es en este caso es que no importa el fragmento como sea, si es igualito, que venga!
pero ¿cuantas probabilidades de encontrar un fragmento similar hay? identificarlos unívocamente y evitar “basura” es fácil con un hash (no digo md5 para que no me descuarticen, pero cualquier otro más complejo), pero no entendí bien cómo piensan aplicarlo en este caso.
La verdad que todo lo que sea “análisis de contenido” en lugar de sólo “análisis de nombres o hashes” hace que se tenga que usar muchísimo más poder de procesamiento y memoria para leer archivos binarios grandes… O sea, no me parece muy práctico. Ganás velocidad en la descarga a través de la red, pero tenés que tener un bruto QuadCore con un par de GB de RAM.
Quedará en el freezer por un tiempo, como el MP3, que fue inventado a finales de los ’80 pero se empezó a usar a mediados de los ’90.
andrea, fabio, la “novedad” es que ahora se buscarán NUEVAS fuentes y NUEVOS fragmentos, cuando bajas del e-mule bajas las fuentes ASIGNADAS, la “novedad” buscará NUEVOS fragmentos NO ASIGNADOS para bajar.
En cuanto a funcionalidad, no me imagino como/quien y sobretodo cuando se va a poder implementar la comparacion de partes y fragmentos. Pero si sería interesante mejorar la velocidad de descarga de la red p2p.