Gnutella

Dans Gnutella v0.4, chaque poste agit comme un serveur et un client et est nommé « servent » (contraction de serveur et client).

Chaque serveur est connecté à un ensemble de voisins. Pour lancer une recherche, un serveur interroge tous ses voisins en leur envoyant un message de recherche. Ses voisins font de même avec leurs propres voisins. Un champ TTL (Time To Live) est associé au message de recherche pour comptabiliser le nombre de retransmissions restantes. Quand celle-ci est nulle, le message n'est plus renvoyé. Cette méthode de propagation est appelée inondation.

Les serveurs ayant des fichiers qui répondent à la requête renvoient leur réponse (nom du fichier + leur adresse IP) au voisin qui leur a retransmis la requête. La réponse remonte ainsi de proche en proche jusqu'au serveur qui a initié la requête.

Le serveur initiateur de la requête va ensuite choisir les fichiers à télécharger en envoyant directement une requête de téléchargement au serveur qui possède le fichier.

Cependant cette inondation est coûteuse en bande passante et les recherches sont plus lentes que dans les réseaux centralisés (Napster).

Publié en 2002[2].

Ce qui conduit les développeurs du logiciel LimeWire à proposer en 2001 le système d'ultrapeers. La gestion des ultrapeer (ou superpeer) est incluse dans la version 0.6 du protocole Gnutella. Les serveurs sont divisés en deux catégories : les ultrapeers (ou superpeer) qui sont des serveurs stables ayant une bonne connectivité et les clients (ou nœuds feuilles). Les feuilles (leaf) sont rattachées à 3 ultrapeers et les ultrapeers admettent entre 30 et 45 clients et 30 ultrapeers. Les ultrapeers indexent le contenu des clients auxquels ils sont rattachés et répondent aux requêtes de recherche en incluant les documents de leur clients.

Les requêtes de recherches reçues par les ultrapeers ne sont retransmises qu'aux autres ultrapeers. Ainsi un client interrogeant un ultrapeer peut rechercher sur 30 autres clients avec une seule requête. Si la requête est retransmise aux 30 autres ultrapeers auquel il est connecté, sa recherche atteint le contenu de 900 clients... Autre point non négligeable, les clients ne reçoivent plus de requêtes de recherche, on dit qu'ils sont protégés (shielded) par leur ultrapeer. Cela permet en outre aux utilisateurs connectés à Internet en bas débit de pouvoir utiliser Gnutella sans diminuer leurs performances.

GUESS (Gnutella UDP Extension for Scalable Searches) permet aux feuilles de contrôler le nombre d'ultrapeers interrogés et donc de réduire la bande passante utilisée.

Pour satisfaire, une recherche sur des mots populaires, il y a besoin d'interroger peu d'ultrapeers pour obtenir un nombre de résultats satisfaisants. Au contraire, une recherche sur des ressources rares demande d'interroger un nombre important d'ultrapeers.

Avec le mécanisme par inondation, il est impossible de contrôler efficacement le nombre d'ultrapeers interrogés. La solution proposée par GUESS est de laisser à l'initiateur de la recherche le soin d'interroger successivement un ensemble d'ultrapeers jusqu'à ce qu'il obtienne un nombre de résultats satisfaisants.

GWebcache fonctionne sous la forme d'un script installé sur un serveur web, destiné à permettre à des clients Gnutella de récupérer une liste de nœuds Gnutella auxquels il est possible de se connecter. Typiquement, lors de la première connexion au réseau Gnutella, les serveurs ne connaissent pas d'autres serveurs auxquels se connecter. Cette étape est connue sous le nom de bootstrap.

Les GWebCaches sont accessibles via une adresse URL et utilisent le protocole HTTP (serveurs HTTP rudimentaires).

Le protocole GWebcache spécifie deux types de requêtes :

• les requêtes GET pour récupérer une liste d'adresses IP de nœuds Gnutella et d'URLs pointant sur d'autres serveurs GWebCaches.
• les requêtes UPDATE permettant à un serveur d'informer le GWebCache qu'un ultrapeer ou un serveur GWebCache est présent dans le réseau.

Le serveur maintient une liste limitée d'adresses IP des ultrapeers et d'URLs de GWebCaches et ne garde que les dernières reçues. Cela permet de garantir que les adresses des ultrapeers et des GWebCaches retournés à un client soient toujours fraîches et donc aient de grande chances d'être encore accessibles.

Gnutella2 (aussi surnommé G2) : En dépit de son nom, il n'est pas un successeur du protocole Gnutella, c'est un "fork" (fourche, déviation) initié en 2002. Un point de controverse avec de nombreux développeurs de Gnutella, c'est que le nom "Gnutella2" traduit une mise à niveau ou de supériorité, ce qui a conduit à une "guerre de flame Gnutella2". D'autres critiques sont l'utilisation du réseau Gnutella pour l'amorçage de pairs G2, et la piètre documentation du protocole G2.

Gnutella2 a été mis au point par Michael Stokes (le programmeur d'origine de Shareaza). Il reprend quelques caractéristiques de Gnutella, comme la connexion initiale, par exemple, mais il a une topologie, ainsi qu'un algorithme de recherche complètement différent.

• Partage de fichiers en pair à pair
• Gnutella 2 (EN)

• The Gnutella Developper Forum (GDF)
• D. Stutzbach and R. Rejaie.Characterizing Today's Gnutella Topology. Proceedings of the ACM SIGMETRICS, Poster Session, Alberta Canada, June 2005.
• Gnutella Web Caching System : Version 2 Specifications Client Developers's Guide.
• S. Daswani and A. Fisk. Gnutella UDP Extension for Scalable Search (GUESS) v0.1.
• B. Yang, P. Vinograd, and H. Garcia-Molina. Evaluating GUESS and Non-Forwarding Peer-to-Peer Search. 24th International Conference on Distributed Computing Systems (ICDCS 2004), 24-26 March 2004, Hachioji, Tokyo, Japan, p. 209-218, 2004