Este artículo, segunda parte de una serie sobre Gnutella, explica cómo la red peer-to-peer resolvió sus problemas de escalabilidad sin renunciar a la descentralización. En su apogeo, LimeWire llegó a instalarse en un tercio de los ordenadores de sobremesa y mantuvo varios millones de nodos concurrentes, todo ello sin un índice global de archivos ni servidores de coordinación.
El texto parte del flood routing, el método simple con el que Gnutella empezó: cada consulta se reenviaba a todos los vecinos hasta agotar los saltos (TTL). Aunque eficaz en redes pequeñas, este modelo generaba un consumo de ancho de banda exponencial porque la mayoría de los nodos收到cían mensajes irrelevantes. Cuando Gnutella alcanzó millones de usuarios, esta arquitectura dejó de ser viable, y hacia 2003 cayó en desuso.
Para superarlo, los clientes posteriores adoptaron el Query Routing Protocol (QRP). Cada peer publicaba una representación compacta y aproximada de los términos de búsqueda disponibles tras él. Cuando llegaba una consulta, un ultrapeer (nodo con ancho de banda, tiempo activo y memoria suficientes) podía filtrar qué hojas tenían “posiblemente” archivos relevantes antes de reenviar la consulta. Así se reducían los falsos positivos sin necesidad de revelar listas exactas de archivos compartidos.
El artículo describe la arquitectura de dos niveles —hojas y ultrapeers—, detalla el funcionamiento de las tablas QRP, aclara la diferencia entre falsos positivos y falsos negativos, y explica por qué este diseño permitió a Gnutella escalar mejor manteniendo su naturaleza descentralizada, sentando las bases de las redes P2P modernas.