Gnutella es un protocolo de red peer-to-peer . Fundada en 2000, fue la primera red descentralizada de igual a igual 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 ordenadores [2] aumentando a más de tres millones de nodos en enero de 2006. [3] A finales de 2007, era la red para compartir archivos más popular en Internet con una cuota de mercado estimada de más de 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 parte de AOL . El 14 de marzo, el programa estuvo disponible 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 motivos legales e impidió 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 , gratuitos y de código abierto . [10] Este desarrollo paralelo de diferentes clientes por diferentes grupos sigue siendo el modus operandi del desarrollo de Gnutella en la actualidad.
Entre los primeros pioneros independientes de Gnutella se encuentran 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 pioneros de código abierto. (GNU-GPL) programas para implementar el protocolo Gnutella. [13] [14] [15]
La red Gnutella es una alternativa totalmente distribuida a sistemas semicentralizados como FastTrack ( KaZaA ) y el Napster original . La popularidad inicial de la red fue impulsada por la amenaza de desaparición legal de Napster a principios de 2001. Este creciente aumento de popularidad reveló los límites de la escalabilidad del protocolo inicial. A principios de 2001, las variaciones en el 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 solicitudes de búsqueda y respuestas para los usuarios conectados a ellos.
Esto permitió que la red ganara popularidad. A finales de 2001, el cliente 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 Gnutella, gratuito y de código abierto, Gnucleus .
La palabra Gnutella hoy no se refiere a ningún proyecto o pieza de software, sino al protocolo abierto utilizado por los distintos clientes.
El nombre es un acrónimo de GNU y Nutella , la marca de una pasta 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 GNU. Gnutella no está asociado con el proyecto GNU [16] ni con la propia red peer-to-peer de GNU, GNUnet .
El 26 de octubre de 2010, el 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 que los demandantes de la industria discográfica y LimeWire habían aceptado. Este evento fue la causa probable de una caída notable [17] en el tamaño de la red, porque, mientras negociaba 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 las versiones afectadas (más recientes que la 5.5.10) quedaron excluidos de la red P2P . Dado que LimeWire era software libre , nada había impedido la creación de bifurcaciones que omitían el código de desactivación, siempre y cuando no se utilizaran las marcas comerciales 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 el adware .
El 9 de noviembre de 2010, LimeWire fue resucitado por un equipo secreto de desarrolladores y lo llamó LimeWire Pirate Edition . [18] Estaba basado en LimeWire 5.6 BETA. A esta versión se le eliminaron las dependencias del servidor y se habilitaron todas las funciones PRO de forma gratuita.
Para imaginar cómo funcionó originalmente Gnutella, imagine un gran círculo de usuarios (llamados nodos), cada uno de los cuales tiene el software cliente Gnutella. En el inicio inicial, el software cliente debe iniciarse 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 incluidos con el software, utilizando cachés web actualizados de nodos conocidos (llamados Gnutella Web Caches ), cachés de host UDP y, rara vez, incluso IRC . Una vez conectado, el cliente solicita una lista de direcciones de trabajo. 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 determinada cuota. Se conecta solo a esa cantidad de nodos, almacena en caché localmente las direcciones que aún no ha probado y descarta las direcciones que probó y encontró que no eran válidas. [19]
Cuando el usuario quiere realizar una búsqueda, el cliente envía la solicitud a cada nodo conectado activamente. En la versión 0.4 del protocolo, la cantidad de nodos conectados activamente para un cliente era bastante pequeña (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 haya alcanzado un número predeterminado de saltos desde el remitente (máximo 7). [20]
Desde la versión 0.6 (2002 [21] ), Gnutella es una red compuesta formada por nodos hoja y ultranodos (también llamados ultrapeers). Los nodos hoja están conectados a una pequeña cantidad de ultrapeers (normalmente 3), mientras que cada ultrapeer está conectado a más de otros 32 ultrapeers. Con este grado superior , la cantidad máxima de saltos que puede recorrer una consulta se redujo a 4.
Las hojas y los ultrapeers utilizan el protocolo de enrutamiento de consultas para intercambiar una tabla de enrutamiento de consultas (QRT), una tabla de 64 ranuras Ki y hasta 2 ranuras Mi que constan de palabras clave hash. Un nodo hoja envía su QRT a cada uno de los ultrapeers a los que está conectado, y los ultrapeers fusionan el QRT de todas sus hojas (reducido a 128 Ki -slots) más su propio QRT (si comparten archivos) y lo intercambian con el suyo propio. vecinos. Luego, el enrutamiento de consultas se realiza aplicando hash a las palabras de la consulta y viendo si todas coinciden en el QRT. Los ultrapeers hacen esa verificación antes de reenviar una consulta a un nodo hoja, y también antes de reenviar la consulta a un ultranodo par, siempre que este sea el último salto por el que puede viajar la consulta.
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 clásico de Gnutella, los mensajes de respuesta se enviaban a lo largo de la ruta tomada por la consulta, ya que la consulta en sí no contenía información de identificación del nodo. Este esquema se revisó posteriormente para entregar resultados de búsqueda a través de UDP , directamente al nodo que inició la búsqueda, generalmente un ultrapar del nodo. Así, en el protocolo actual, las consultas llevan la dirección IP y el número de puerto de cualquiera de los nodos. Esto reduce la cantidad de tráfico enrutado a través de la red Gnutella, haciéndola significativamente más escalable. [22]
Si el usuario decide descargar el archivo, negocia la transferencia del archivo . Si el nodo que tiene el archivo solicitado no tiene 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 envía una llamada solicitud de inserción al servidor para que el cliente remoto inicie la conexión (para enviar el archivo). . Al principio, estas solicitudes push se enrutaron a lo largo de la cadena original que utilizó para enviar la consulta. Esto era bastante poco confiable porque las rutas a menudo se interrumpían y los paquetes enrutados siempre estaban sujetos a control de flujo. Se introdujeron proxies push para abordar este problema. Suelen ser los ultrapares de un nodo hoja y se anuncian en los resultados de búsqueda. El cliente se conecta a uno de estos servidores proxy de inserción mediante una solicitud HTTP y el proxy envía una solicitud de inserción a una hoja en nombre del cliente. Normalmente, también es posible enviar una solicitud de inserción a través de UDP al proxy de inserción, lo cual es más eficiente que usar TCP. Los proxies push tienen dos ventajas: primero, las conexiones ultrapeer-leaf son más estables que las rutas. Esto hace que las solicitudes push sean mucho más confiables. En segundo lugar, reduce la cantidad de tráfico encaminado a través de la red Gnutella. [23]
Finalmente, cuando un usuario se desconecta, el software del cliente guarda una lista de nodos conocidos. Contiene los nodos a los que se conectó el cliente y los nodos aprendidos de los paquetes pong. El cliente lo utiliza como lista inicial la próxima vez que se inicia, volviéndose así independiente de los servicios de arranque. [24]
En la práctica, este método de búsqueda en la red Gnutella a menudo no era fiable. Cada nodo es un usuario habitual de computadora; como tal, se conectan y desconectan constantemente, por lo que la red nunca es completamente estable. Además, el costo del ancho de banda de la búsqueda en Gnutella creció exponencialmente con la cantidad de usuarios conectados, [25] a menudo saturando las conexiones y volviendo inútiles los nodos más lentos. Por lo tanto, las solicitudes de búsqueda a menudo se descartaban y la mayoría de las consultas llegaban sólo a una parte muy pequeña de la red. Esta observación identificó 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 palabras clave. [26]
Para abordar los problemas de los cuellos de botella , los desarrolladores de Gnutella implementaron un sistema escalonado de ultrapeers y hojas . 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 hoja. Las hojas no proporcionan ruta. Los nodos que son capaces de enrutar mensajes se promocionan a ultrapeers. Los ultrapeers aceptan conexiones hoja y búsquedas de rutas 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. [27]
Además, gnutella adoptó otras técnicas para reducir el tráfico y hacer las búsquedas más eficientes. Los más notables son el Protocolo de enrutamiento de consultas (QRP) y las consultas dinámicas (DQ). Con QRP, una búsqueda llega sólo 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 haya obtenido suficientes resultados de búsqueda. Esto reduce enormemente la cantidad de tráfico generado por búsquedas populares. [28]
Uno de los beneficios de tener Gnutella tan descentralizado es que hace que sea muy difícil cerrar la red y convertirla en 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 cualquier nodo. Una red descentralizada evita que los malos actores tomen el control del contenido de la red y/o manipulen los datos controlando el servidor central. [29]
Gnutella alguna vez operó con un protocolo basado puramente en inundaciones de consultas . El protocolo de red obsoleto Gnutella versión 0.4 emplea cinco tipos de paquetes diferentes, a saber: [30]
Estos paquetes facilitan las búsquedas. En cambio, las transferencias de archivos se manejan mediante HTTP . [31]
El desarrollo del protocolo Gnutella está liderado actualmente por el Gnutella Developers Forum (The GDF). Muchas extensiones de protocolo han sido y están siendo desarrolladas por los proveedores de software y por los desarrolladores gratuitos de Gnutella del GDF. Estas extensiones incluyen enrutamiento de consultas inteligente, sumas de verificació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). [31]
Hay 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 0,4 apretones de manos. Según los desarrolladores del GDF, la versión 0.6 es lo que los nuevos desarrolladores deberían buscar utilizando las especificaciones del trabajo en progreso. [32]
El protocolo Gnutella sigue en desarrollo. A pesar de los intentos de romper con la complejidad heredada del antiguo Gnutella 0.4 y diseñar una nueva arquitectura de mensajes limpia, sigue siendo uno de los protocolos de intercambio de archivos más exitosos hasta la fecha. [33]
Las siguientes tablas comparan información general y técnica para una serie de aplicaciones que soportan la red Gnutella. Las tablas no intentan dar una lista completa de los clientes de Gnutella . Las mesas están limitadas a clientes que pueden participar en la red actual de Gnutella.
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, [36] 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 incendiaria. Otras críticas incluyeron el uso de la red Gnutella para iniciar a los pares G2 y la mala documentación del protocolo G2. Además, los reintentos de búsqueda más frecuentes del cliente Shareaza , uno de los clientes iniciales de G2, podrían sobrecargar innecesariamente la red Gnutella. [37]
Ambos protocolos han sufrido cambios significativos desde su 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 de 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. [38] [39] [40] Una ventaja de Gnutella es su gran base de usuarios, que asciende a millones, [3] . La red G2 es aproximadamente un orden de magnitud más pequeña. [41] Es difícil comparar los protocolos en su forma actual. La elección del cliente, en cualquiera de las redes, probablemente afecte igualmente al usuario final.
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ó aproximadamente un 7 por ciento desde [su] máximo histórico en 2007...
{{cite journal}}: Citar diario requiere |journal=( ayuda ){{cite journal}}: Citar diario requiere |journal=( ayuda ){{cite journal}}: Citar diario requiere |journal=( ayuda )