Gnutella es un protocolo de red peer-to-peer . Fundada en 2000, fue la primera red peer-to-peer descentralizada de su tipo, lo que llevó a otras redes posteriores a adoptar el modelo. [1]
En junio de 2005, la población de Gnutella era de 1,81 millones de computadoras [2], aumentando a más de tres millones de nodos en enero de 2006. [3] A fines de 2007, era la red de intercambio de archivos más popular en Internet con una participación de mercado estimada de más del 40%. [4]
El primer cliente (también llamado Gnutella) del que la red obtuvo su nombre [5] [6] fue desarrollado por Justin Frankel y Tom Pepper de Nullsoft a principios de 2000, poco después de la adquisición de la empresa por AOL . El 14 de marzo, el programa se puso a disposición para su descarga en los servidores de Nullsoft. El evento se anunció prematuramente en Slashdot , y miles de personas descargaron el programa ese día. [7] [8] El código fuente se publicaría más tarde, bajo la Licencia Pública General GNU (GPL); sin embargo, los desarrolladores originales nunca tuvieron la oportunidad de lograr este propósito. [9]
Al día siguiente, AOL detuvo la disponibilidad del programa por cuestiones legales y le prohibió a Nullsoft seguir trabajando en el proyecto. Esto no detuvo a Gnutella; después de unos días, el protocolo había sido sometido a ingeniería inversa y comenzaron a aparecer clones compatibles , libres y de código abierto . [10] Este desarrollo paralelo de diferentes clientes por parte de diferentes grupos sigue siendo el modus operandi del desarrollo de Gnutella en la actualidad.
Entre los primeros pioneros independientes de Gnutella se encontraban Gene Kan y Spencer Kimball , quienes lanzaron el primer portal destinado a reunir a la comunidad de código abierto para trabajar en Gnutella [11] [12] y también desarrollaron "GNUbile", uno de los primeros programas de código abierto (GNU-GPL) en implementar el protocolo Gnutella. [13] [14]
La red Gnutella es una alternativa totalmente distribuida a sistemas semicentralizados como FastTrack ( KaZaA ) y el Napster original . La popularidad inicial de la red se vio impulsada por la amenaza de desaparición legal de Napster a principios de 2001. Este aumento creciente de popularidad reveló los límites de la escalabilidad del protocolo inicial. A principios de 2001, las variaciones del protocolo (implementadas por primera vez en clientes propietarios y de código cerrado ) permitieron una mejora en la escalabilidad. En lugar de tratar a cada usuario como cliente y servidor, algunos usuarios ahora eran tratados como ultrapeers , enrutando las solicitudes de búsqueda y las respuestas para los usuarios conectados a ellos.
Esto permitió que la red creciera en popularidad. A finales de 2001, el cliente de Gnutella, LimeWire Basic, pasó a ser gratuito y de código abierto. En febrero de 2002, Morpheus , un grupo comercial de intercambio de archivos, abandonó su software peer to peer basado en FastTrack y lanzó un nuevo cliente basado en el cliente de Gnutella gratuito y de código abierto Gnucleus .
Hoy en día, la palabra Gnutella no se refiere a un proyecto o pieza de software en particular, sino al protocolo abierto utilizado por los distintos clientes.
El nombre es una combinación de GNU y Nutella , la marca de una crema para untar italiana con sabor a avellana: supuestamente, Frankel y Pepper comieron mucha Nutella mientras trabajaban en el proyecto original y tenían la intención de licenciar su programa terminado bajo la Licencia Pública General de GNU. Gnutella no está asociada con el proyecto GNU [15] ni con la red peer to peer de GNU, GNUnet .
El 26 de octubre de 2010, la juez Kimba Wood del Tribunal de Distrito de los Estados Unidos para el Distrito Sur de Nueva York ordenó el cierre del popular cliente de Gnutella, LimeWire , cuando firmó un decreto de consentimiento al que habían llegado a un acuerdo los demandantes de la industria discográfica y LimeWire. Este evento fue la causa probable de una caída notable [16] en el tamaño de la red, porque, mientras negociaban la orden judicial , el personal de LimeWire había insertado un código de desactivación remota en el software. Cuando la orden judicial entró en vigor, los usuarios que habían instalado versiones afectadas (más nuevas que la 5.5.10) fueron excluidos de la red P2P . Dado que LimeWire era software libre , nada había impedido la creación de bifurcaciones que omitieran el código de desactivación, siempre que no se utilizaran las marcas registradas de LimeWire. El cierre no afectó, por ejemplo, a FrostWire , una bifurcación de LimeWire creada en 2004 que no lleva ni el código de desactivación remota ni adware .
El 9 de noviembre de 2010, un equipo secreto de desarrolladores resucitó LimeWire y lo llamó LimeWire Pirate Edition . [17] Se basó en LimeWire 5.6 BETA. Esta versión tenía sus dependencias del servidor eliminadas y todas las características PRO habilitadas de forma gratuita.
Para visualizar cómo funcionaba originalmente Gnutella, imagine un gran círculo de usuarios (llamados nodos), cada uno de los cuales tiene un software cliente de Gnutella. En el arranque inicial, el software cliente debe arrancar y encontrar al menos otro nodo. Se han utilizado varios métodos para esto, incluida una lista de direcciones preexistente de nodos que posiblemente funcionen y que se incluyen con el software, utilizando cachés web actualizados de nodos conocidos (llamados Gnutella Web Caches ), cachés de host UDP y, raramente, incluso IRC . Una vez conectado, el cliente solicita una lista de direcciones que funcionan. El cliente intenta conectarse a los nodos con los que se envió, así como a los nodos que recibe de otros clientes hasta que alcanza una cierta cuota. Se conecta solo a esa cantidad de nodos, almacenando en caché local las direcciones que aún no ha probado y descartando las direcciones que probó y encontró que no eran válidas. [18]
Cuando el usuario desea realizar una búsqueda, el cliente envía la solicitud a cada nodo conectado activamente. En la versión 0.4 del protocolo, el número de nodos conectados activamente para un cliente era bastante pequeño (alrededor de 5). En esa versión del protocolo, cada nodo reenvía la solicitud a todos sus nodos conectados activamente, quienes, a su vez, reenvían la solicitud. Esto continúa hasta que el paquete ha alcanzado un número predeterminado de saltos desde el remitente (máximo 7). [19]
Desde la versión 0.6 (2002 [20] ), Gnutella es una red compuesta por nodos leaf y nodos ultra (también llamados ultrapeers). Los nodos leaf están conectados a una pequeña cantidad de ultrapeers (normalmente 3), mientras que cada ultrapeer está conectado a más de 32 ultrapeers. Con este grado de salida más alto , la cantidad máxima de saltos que puede recorrer una consulta se redujo a 4.
Los nodos leaf y ultrapeers utilizan el protocolo de enrutamiento de consultas para intercambiar una tabla de enrutamiento de consultas (QRT), una tabla de 64 Ki -slots y hasta 2 Mi -slots que consisten en palabras clave con hash. Un nodo leaf envía su QRT a cada uno de los ultrapeers a los que está conectado, y los ultrapeers fusionan el QRT de todos sus nodos leaf (reducido a 128 Ki -slots) más su propio QRT (si comparten archivos) y lo intercambian con sus propios vecinos. El enrutamiento de consultas se realiza luego mediante el hash de las palabras de la consulta y viendo si todas coinciden en el QRT. Los ultrapeers realizan esa verificación antes de reenviar una consulta a un nodo leaf, y también antes de reenviar la consulta a un nodo ultra peer, siempre que este sea el último salto que la consulta puede recorrer.
Si una solicitud de búsqueda arroja un resultado, el nodo que tiene el resultado se pone en contacto con el buscador. En el protocolo Gnutella clásico, los mensajes de respuesta se enviaban de vuelta a lo largo de la ruta tomada por la consulta, ya que la consulta en sí no contenía información de identificación para el nodo. Este esquema fue revisado más tarde, para entregar los resultados de la búsqueda a través de UDP , directamente al nodo que inició la búsqueda, generalmente un ultrapeer del nodo. Por lo tanto, en el protocolo actual, las consultas llevan la dirección IP y el número de puerto de cada nodo. Esto reduce la cantidad de tráfico enrutado a través de la red Gnutella, lo que la hace significativamente más escalable. [21]
Si el usuario decide descargar el archivo, negocia la transferencia del archivo . Si el nodo que tiene el archivo solicitado no tiene un firewall , el nodo que realiza la consulta puede conectarse a él directamente. Sin embargo, si el nodo tiene un firewall, lo que impide que el nodo de origen reciba conexiones entrantes, el cliente que desea descargar un archivo le envía una llamada solicitud push al servidor para que el cliente remoto inicie la conexión en su lugar (para enviar el archivo). Al principio, estas solicitudes push se enrutaban a lo largo de la cadena original que se usaba para enviar la consulta. Esto era bastante poco confiable porque las rutas a menudo se rompían y los paquetes enrutados siempre están sujetos al control de flujo. Los proxies push se introdujeron para abordar este problema. Estos suelen ser los ultrapeers de un nodo leaf y se anuncian en los resultados de búsqueda. El cliente se conecta a uno de estos proxies push mediante una solicitud HTTP y el proxy envía una solicitud push a una leaf en nombre del cliente. Normalmente, también es posible enviar una solicitud push a través de UDP al proxy push, que es más eficiente que usar TCP. Los servidores proxy push tienen dos ventajas: en primer lugar, las conexiones entre ultrapeer y leaf son más estables que las rutas, lo que hace que las solicitudes push sean mucho más confiables. En segundo lugar, reducen la cantidad de tráfico enrutado a través de la red Gnutella. [22]
Finalmente, cuando un usuario se desconecta, el software cliente guarda una lista de nodos conocidos. Esta contiene los nodos a los que el cliente estaba conectado y los nodos aprendidos a partir de los paquetes pong. El cliente utiliza esa lista como su lista de nodos de inicio la próxima vez que se inicia, volviéndose así independiente de los servicios de arranque. [23]
En la práctica, este método de búsqueda en la red Gnutella era a menudo poco fiable. Cada nodo es un usuario de ordenador normal; como tal, se conectan y desconectan constantemente, por lo que la red nunca es completamente estable. Además, el coste del ancho de banda de la búsqueda en Gnutella crecía exponencialmente en función del número de usuarios conectados, [24] a menudo saturando las conexiones y haciendo inútiles los nodos más lentos. Por tanto, las solicitudes de búsqueda se descartaban a menudo y la mayoría de las consultas llegaban solo a una parte muy pequeña de la red. Esta observación identificó a la red Gnutella como un sistema distribuido no escalable e inspiró el desarrollo de tablas hash distribuidas , que son mucho más escalables pero solo admiten búsquedas de coincidencia exacta, en lugar de búsquedas por palabras clave. [25]
Para abordar los problemas de cuellos de botella , los desarrolladores de Gnutella implementaron un sistema escalonado de ultrapeers y leaves . En lugar de que todos los nodos se consideraran iguales, los nodos que ingresaban a la red se mantenían en el "borde" de la red, como una leaf. Las leaves no proporcionan enrutamiento. Los nodos que son capaces de enrutar mensajes se promueven a ultrapeers. Los ultrapeers aceptan conexiones leaf y enrutan búsquedas y mensajes de mantenimiento de red. Esto permite que las búsquedas se propaguen más a través de la red y permite numerosas alteraciones en la topología. Esto mejoró enormemente la eficiencia y la escalabilidad. [26]
Además, gnutella adoptó una serie de otras técnicas para reducir la sobrecarga de tráfico y hacer que las búsquedas sean más eficientes. Las más notables son el Protocolo de enrutamiento de consultas (QRP) y la Consulta dinámica (DQ). Con QRP, una búsqueda llega solo a aquellos clientes que probablemente tengan los archivos, por lo que las búsquedas de archivos raros se vuelven mucho más eficientes. Con DQ, la búsqueda se detiene tan pronto como el programa ha obtenido suficientes resultados de búsqueda. Esto reduce enormemente la cantidad de tráfico causado por las búsquedas populares. [27]
Una de las ventajas de que Gnutella esté tan descentralizada es que hace que sea muy difícil apagar la red y que sea una red en la que los usuarios sean los únicos que puedan decidir qué contenido estará disponible. A diferencia de Napster , donde toda la red dependía del servidor central, Gnutella no se puede apagar apagando un nodo. Una red descentralizada evita que actores maliciosos tomen el control de los contenidos de la red y/o manipulen los datos controlando el servidor central. [28]
Gnutella alguna vez funcionó con un protocolo basado exclusivamente en inundaciones de consultas . El protocolo de red Gnutella versión 0.4, que ya no está actualizado , emplea cinco tipos de paquetes diferentes, a saber: [29]
Estos paquetes facilitan las búsquedas. Las transferencias de archivos se gestionan mediante HTTP . [30]
El desarrollo del protocolo Gnutella está actualmente a cargo del Foro de Desarrolladores de Gnutella (GDF). Los proveedores de software y los desarrolladores de Gnutella libre del GDF han desarrollado y están desarrollando muchas extensiones del protocolo. Estas extensiones incluyen enrutamiento inteligente de consultas, sumas de comprobación SHA-1 , transmisión de consultas a través de UDP , consultas a través de UDP, consultas dinámicas a través de TCP , transferencias de archivos a través de UDP, metadatos XML , intercambio de fuentes (también denominado malla de descarga ) y descarga paralela en porciones (enjambre). [30]
Se están realizando esfuerzos para finalizar estas extensiones de protocolo en la especificación Gnutella 0.6, en el sitio web de desarrollo del protocolo Gnutella. El estándar Gnutella 0.4 está desactualizado, pero sigue siendo la última especificación de protocolo porque todas las extensiones, hasta ahora, existen como propuestas. De hecho, hoy en día es difícil o imposible conectarse con los protocolos de enlace 0.4. Según los desarrolladores del GDF, la versión 0.6 es lo que los nuevos desarrolladores deberían buscar utilizando las especificaciones en proceso de desarrollo. [31]
El protocolo Gnutella sigue en desarrollo. A pesar de los intentos de romper con la complejidad heredada del antiguo Gnutella 0.4 y de diseñar una nueva arquitectura de mensajes, sigue siendo uno de los protocolos de intercambio de archivos más exitosos hasta la fecha. [32]
Las siguientes tablas comparan información general y técnica de una serie de aplicaciones que admiten la red Gnutella. Las tablas no pretenden ofrecer una lista completa de los clientes de Gnutella . Las tablas se limitan a los clientes que pueden participar en la red Gnutella actual.
Proyecto discontinuado
El protocolo Gnutella2 (a menudo denominado G2), a pesar de su nombre, no es un protocolo sucesor de Gnutella ni está relacionado con el proyecto Gnutella original, [35] sino que es un protocolo completamente diferente que se bifurcó del proyecto original y se aprovechó del nombre Gnutella. Un punto delicado para muchos desarrolladores de Gnutella es que el nombre Gnutella2 transmite una mejora o superioridad, lo que llevó a una guerra de comentarios. Otras críticas incluyeron el uso de la red Gnutella para arrancar pares G2 y la documentación deficiente del protocolo G2. Además, los reintentos de búsqueda más frecuentes del cliente Shareaza , uno de los clientes G2 iniciales, podrían sobrecargar innecesariamente la red Gnutella. [36]
Ambos protocolos han sufrido cambios significativos desde la bifurcación en 2002. G2 tiene ventajas y desventajas en comparación con Gnutella. Una ventaja que se cita a menudo es que la búsqueda híbrida de Gnutella2 es más eficiente que la inundación de consultas del Gnutella original . Sin embargo, Gnutella reemplazó la inundación de consultas con métodos de búsqueda más eficientes, comenzando con Query Routing en 2002. Esto fue propuesto en 2001 por los desarrolladores de Limewire. [37] [38] [39] Una ventaja de Gnutella es su gran base de usuarios, que se cuentan por millones. [3] La red G2 es aproximadamente un orden de magnitud más pequeña. [40] Es difícil comparar los protocolos en su forma actual. La elección del cliente, en cualquiera de las redes, probablemente afecta al usuario final tanto como sea posible.
A raíz del cierre de LimeWire, el porcentaje de usuarios de Internet de EE. UU. que acceden a servicios de intercambio de archivos P2P cayó alrededor de un 7 por ciento desde [su] máximo histórico en 2007...
{{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite journal}}: Requiere citar revista |journal=( ayuda )