Les réseaux non-structurés

Dans les approches non structurées, le réseau P2P est créé de manière non-déterministe. Dans ce type d’approches, le placement des données dans le réseau est indépendant du réseau virtuel lui-même. Par conséquent, un nœud peut connaître ses voisins dans le réseau mais il ne connaît pas les données qu’ils stockent. Le placement de données dans ce type de réseau est effectué en général sur le nœud demandeur. Par ailleurs, la recherche d’une donnée sur ce type de réseau est réalisée par inondation, la localisation de la donnée n’étant à priori pas connue. La recherche peut concerner une donnée particulière ou un ensemble. Les approches dans ce domaine donnent lieu à des systèmes tolérants aux fautes et où les nœuds sont très autonomes. Par contre, la recherche d’une donnée dans un réseau avec un grand nombre de nœuds peut être longue et ne donne que des résultats partiels.

Différents niveaux de décentralisation scindent les réseaux non-structurés en deux modèles: le modèle centralisé et le modèle purement décentralisé.

4.2.1.1 Le modèle centralisé

Le modèle centralisé est à la limite du modèle P2P car il repose sur un serveur dédié qui centralise et maintient l’ensemble des connaissances de la communauté, les ressources étant toujours hébergées sur les pairs. Ce modèle est utilisé dans des applications telle que Napster [S01]. Dans un modèle centralisé chaque pair ne possède au minimum qu’une connaissance du serveur central et pas des autres pairs, bien qu’une fois les opérations de découverte et localisation effectuées, il puisse interagir directement avec eux. Ainsi, cette interaction possible entre les pairs différencie le modèle P2P centralisé du modèle client-serveur. Nous présentons dans cette section l’application Napster comme exemple du modèle P2P centralisé.

Napster [S01] est une application de partage de fichiers musicaux mp3. Le service est

fondé par Shawn Fanning et Sean Parker. Napster utilise un modèle P2P à répertoire centralisé pour les données administratives et les index des fichiers mp3 téléchargeables par les pairs. Un pair se connecte directement sur le serveur. Le protocole basique est simple, avec des primitives de service : login request, login OK, login failed, user

Chapter 2 - Etat de l’Art 39

Figure 16. Les échanges dans Napster

Le pair communique au serveur central la liste des fichiers qu’il partage, ainsi qu’un numéro de port TCP où il pourra être contacté pour un téléchargement. Les pairs sont donc les fournisseurs de fichiers, et les échanges vont se faire directement entre eux. La recherche et le téléchargement vont se passer de la manière représentée sur la Figure 16: un pair recherchant un fichier va envoyer sa requête au serveur central (1), qui va lui répondre par une liste triée de pairs qui hébergent le fichier recherché (2). Le pair va alors choisir parmi les réponses celle qui lui convient le mieux (pertinence de la réponse, bande passante, taille du fichier, …) et contacte directement le pair choisi. Le téléchargement s’effectue alors directement entre les deux pairs (3).

4.2.1.2 Le modèle purement décentralisé

Dans un modèle purement décentralisé, chaque pair joue à la fois le rôle d’un client et d’un serveur. Chaque pair est connecté à un ensemble de voisins. Pour lancer une recherche, un pair 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 pairs 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 pair qui a initié la requête. Le pair initiateur de la requête va ensuite choisir les fichiers à télécharger en envoyant directement une requête de téléchargement au pair 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 (par exemple Napster). Nous présentons dans cette section l’application Gnutella [MPV06] comme exemple du modèle P2P purement décentralisé.

Gnutella [MPV06] est un protocole de fichiers partagés. La première version (version

0.4) date de mars 2000. Cette application a montré qu’il est possible de proposer aux usagers un service qui ne repose sur aucune infrastructure physique concrète mais sur

Chapter 2 - Etat de l’Art 40 un simple logiciel distribué au sein d’une communauté d’utilisateurs. Dans Gnutella, chaque pair dispose de 6 types de messages principaux:

• Ping : Utilisé pour découvrir les autres pairs sur le réseau. Un pair qui reçoit un Ping doit répondre avec un ou plusieurs Pong.

• Pong : C’est la réponse à un Ping; ce message contient l’adresse IP et le port du

pair qui répond, ainsi qu’une information sur les fichiers et leurs tailles partagés par celui-ci.

• Query : Message pour la recherche de fichier sur le réseau. Un pair qui reçoit un Query répondra par un Query Hit s’il trouve une correspondance avec un ou

plusieurs de ses fichiers partagés et les critères de recherche.

• Query Hit : C’est la réponse à un Query. • Get: téléchargement des données.

• Push : Permet de télécharger des données depuis un pair qui se trouve derrière un

Firewall.

Bien que le réseau supporte des milliers d’usagers, son mécanisme de flooding amène des limites, et ne semble pas supporter le passage à l’échelle (Réseau rapidement inondé par des Ping et des Pong). Son mécanisme de recherche présente une limite, fixée par la valeur initiale du TTL. Ainsi une requête peut être stoppée par une expiration de TTL sans avoir parcouru l’intégralité du réseau et retourner une réponse négative.