Les r´ eseaux pair-` a-pair

Les r´eseaux pair-`a-pair se sont d´evelopp´es en mˆeme temps que la d´emocratisation de l’Internet dans le courant des ann´ees 1990. De par leur aspect distribu´e qui rend leur opti- misation complexe, ils ont ´et´e sans cesse am´elior´es au cours des ann´ees et se retrouvent dans de nombreuses applications tr`es h´et´erog`enes.

2.5.1 L’´evolution des r´eseaux pair-`a-pair

La premi`ere g´en´eration de protocoles pair-`a-pair populaires concernant l’´echange de fi- chiers a d´emarr´e avec l’arriv´ee de Napster (Carlsson et Gustavsson (2001)) en 1999 d´evelopp´e par Shawn Fanning et Sean Parker afin de faciliter en particulier l’´echange de fichiers musi- caux. Le protocole ´etait bas´e sur un serveur indexant tous les nœuds du r´eseau et enregistrant ´

egalement les fichiers ou morceaux de fichiers mis `a disposition par chacun d’entre eux que l’on appelait tracker. Lorsqu’un nœud d´esirait obtenir une ressource, il faisait une requˆete `a ce serveur qui lui indiquait les nœuds la poss´edant et ´etant disponibles pour la lui envoyer.

La vaste majorit´e des fichiers partag´es ´etant des fichiers sous droit d’auteur ´echang´es sans aucune consid´eration l´egale, la justice am´ericaine condamna Napster en 2001 suite `a une plainte de la RIAA (Recording Industry Association of America). Napster ob´eit `a l’injonc- tion de d´econnecter son tracker, point central du r´eseau, ce qui entraˆına sa mort imm´ediate.

C’est suite `a cette exp´erience de d´eboires judiciaires, et au del`a de l’aspect r´eseautique visant `a optimiser les protocoles et l’usage du r´eseau, que les protocoles suivants ont cherch´e `

a ´eviter au maximum toute centralisation dans leur impl´ementation en particulier concer- nant le probl`eme d’indexation. L’id´ee principale des protocoles de deuxi`eme g´en´eration est donc de d´ecentraliser au maximum la base de donn´ees d’indexation et de la r´epartir ou de la dupliquer sur le plus de nœuds possible tout en gardant un r´eseau efficace et efficient.

C’est ainsi que GNutella a vu le jour et est devenu tr`es populaire. Dans un premier temps, et jusqu’`a la version 0.6, le protocole reprend l’id´ee d’un serveur centralisateur mais redon- dant. Le nouveau nœud souhaitant se connecter au r´eseau se connecte `a l’un des ces serveurs dont on lui a fourni l’adresse, pour r´ecup´erer la liste de tous les autres serveurs. Ces serveurs sont r´eput´es ˆetre connect´es en permanence. Si un serveur venait `a ne plus r´epondre, les clients effectueraient leur requˆete `a l’un des autres serveurs. Il existait ´egalement un m´ecanisme de synchronisation entre ces diff´erents serveurs pour disposer de la mˆeme information. Par la suite, le protocole s’est am´elior´e en permettant de s´electionner ces serveurs de mani`ere dyna- mique parmi les nœuds faisant partie du r´eseau. Ces nœuds sont connus sous le vocable de supernœud et sont choisis en fonction de leur capacit´e de connexion (d´ebit, gigue, latence) et du la dur´ee de connexion au r´eseau. Fastrack reprendra ce principe en gardant la hi´erarchie des diff´erents pairs et il sera utilis´e par des logiciels qui ont ´et´e tr`es populaires comme KaZaA entre autre.

Dans la mˆeme p´eriode, courant 2001, Bram Cohen, ing´enieur informatique, cr´ee ce qui est encore aujourd’hui le protocole pair-`a-pair le plus populaire : Bittorent. Ce nouveau protocole apporte une avanc´ee majeure compar´e `a ces pr´ed´ecesseurs. Le transfert de fichiers, apr`es recherche de nœuds poss´edant la ressource d´esir´ee, ne se fait plus avec un seul pair mais avec plusieurs. Chaque fichier partag´e est donc divis´e pr´ealablement en plusieurs morceaux appel´es chunk et pouvant ˆetre t´el´echarg´es de diff´erentes sources de mani`ere ind´ependante alors que jusqu’ici cela se faisait en un seul et unique bloc. Il en r´esulte ainsi, une bien meilleure utilisation de la bande passante disponible du r´eseau pair-`a-pair, puisqu’un pair peut rapatrier dor´enavant plusieurs morceaux d’un mˆeme fichier provenant de plusieurs pairs en mˆeme temps, ce qui est particuli`erement efficace sur des connexions Internet asym´etriques comme

l’ADSL o`u la bande passante montante est bien inf´erieure `a la bande passante descendante des diff´erents nœuds. De plus, il est dor´enavant possible de partager une partie d’un fichier alors mˆeme que la totalit´e du fichier n’a pas encore ´et´e t´el´echarg´ee. Cela acc´el`ere donc de mani`ere drastique les partages de nouveaux fichiers mis `a disposition.

2.5.2 R´eseaux pair-`a-pair structur´es et r´eseaux non-structur´es

Les r´eseaux pair-`a-pair sont class´es en deux grandes cat´egories : les r´eseaux dits non- structur´es et les r´eseaux structur´es.

Les premiers r´eseaux pair-`a-pair ´etaient historiquement non-structur´es. Lorsqu’un nœud souhaitait trouver un autre nœud poss´edant une ressource voulue, celui-ci n’avait aucune id´ee des nœuds pr´esents sur le r´eseau poss´edant potentiellement le contenu. La recherche se faisait principalement au d´ebut par inondation pure du r´eseau. Le nœud demandait ainsi `

a ses voisins, c’est-`a-dire les autres nœuds du r´eseau dont il connaissait l’existence, s’ils poss´edaient la ressource d´esir´ee. Si la r´eponse ´etait n´egative, ces voisins demandaient alors `a leurs voisins qui tentaient `a leur tour de satisfaire la requˆete, et ainsi de suite. Potentiellement, si la ressource recherch´ee n’´etait pas pr´esente sur le r´eseau, l’ensemble des pairs aurait re¸cu une demande la concernant. L’efficience d’algorithmes de ce type, appel´es uninformed BFS (Chen et al. (2007)), ´etait tr`es mauvaise et d’autres algorithmes meilleurs ont par la suite ´et´e propos´es, comme le protocole k-Random Walk par exemple. (Lv et al. (2002))

Les algorithmes de routage sur les r´eseaux non-structur´es ne sont malheureusement pas tr`es efficaces, puisque les pairs pris individuellement n’ont aucune id´ee, mˆeme approximative, de l’endroit o`u peuvent se trouver les ressources d´esir´ees. A contrario, les r´eseaux structur´es permettent de connaˆıtre un sous ´echantillon de pairs d’avantage susceptibles de poss´eder la ressource. La contrepartie est de devoir imposer des contraintes structurelles plus ´elev´ees au r´eseau.

Ce type de r´eseau fonctionne la plupart du temps avec un m´ecanisme de r´eseau superpos´e (overlay network ) o`u les machines faisant partie du r´eseau pair-`a-pair fonctionnent sur un r´eseau virtuel logique avec un nouvel adressage qui lui est propre. Ce r´eseau fonctionne sur le r´eseau existant, comme Internet par exemple, d’o`u le nom de ”superpos´e”. La plupart des impl´ementations et des algorithmes utilis´es dans les r´eseaux structur´es fonctionnent avec un syst`eme de tables de hachage distribu´ees (Distributed hash table ou plus connues sous l’acronyme DHT ).

2.5.3 Les tables de hachage distribu´ees

Face au d´esir de d´ecentraliser la base de donn´ees charg´ee de r´ef´erencer la localisation et la disponibilit´e des fichiers sur le r´eseau, les concepteurs de protocoles pair-`a-pair ont propos´e un syst`eme de r´epartition de cette base appel´ee DHT pour tables de hachage distribu´ees. Chaque fichier ou morceau de fichier se voit associ´e un hash par le biais d’un fonction de hachage comme md5, sha-1 ou sha-256. En pratique, chaque hash associ´e est r´eput´e suffisamment unique, c’est `a dire que la probabilit´e d’avoir un hash identique entre deux valeurs diff´erentes est tr`es faible. Les valeurs sont ensuite enregistr´ees sous la forme d’un couple <clef,valeur> et stock´ees dans un ordre qui d´epend du hash de la clef. La figure 2.4 donne un exemple d’une table de hachage o`u, `a partir d’un nom utilis´e comme clef, on r´eussit `a trouver le num´ero de t´el´ephone associ´e grˆace au hash calcul´e `a partir de la clef (le nom ici), ces derniers ´etant class´es selon leur hash.

FIGURE 2.4 Exemple de tables de hachage.

Une table DHT reprend donc la notion de table de hachage mais en la distribuant sur plu- sieurs nœuds. Ainsi, cette derni`ere se retrouve morcel´ee sur plusieurs nœuds qui ne poss`edent qu’une partie de la table de hachage. Bien ´evidemment, chaque nœud pouvant se d´econnecter `

a n’importe quel moment, la table de hachage est distribu´ee de mani`ere redondante. Ce type de r´eseau pair-`a-pair a n´ecessairement besoin de s’appuyer sur un r´eseau structur´e comme vu pr´ec´edemment pour joindre facilement et efficacement des nœuds ayant la partie de la table de hachage d´esir´ee par le demandeur. De multiples protocoles d’indexation utilisant les DHT ont ´et´e propos´es et impl´ement´es dans des logiciels pair-`a-pair comme CAN, Chord, Pastry ou Tapestry (Stoica et al. (2001)). Aujourd’hui, le protocole le plus populaire et que l’on retrouve dans les impl´ementations r´ecentes notamment de Bittorent se nomme Kademlia.