Protocoles de routage au sein de r´ eseaux structur´ es

Les protocoles de routages au sein d’un r´eseau P2P structur´e ´etant un domaine actif de recherche, plusieurs solutions ont ´et´e d´evelopp´ees et test´ees avec succ`es comme l’indique la r´ef´erence [21]. Aussi ai-je d´ecid´e de n’en pr´esenter qu’une s´election dont les m´ecanismes forment les bases de ce type de protocoles. Dans cette section, les protocoles de routage Chord, CAN et Pastry sont r´esum´es.

CAN

CAN, ou Content Addressable Network [30], est une infrastructure P2P distribu´ee et d´ecentralis´ee permettant les fonctionnalit´e d’une table de hashage distribu´ee `a l’´echelle d’Internet. Le design de cette infrastructure est telle qu’elle permet `a CAN d’ˆetre exten-sible, tol´erante aux fautes et auto-adaptative⁷. Son architecture utilise un espace cart´esien de dimension d qui est dynamiquement r´eparti entre les diff´erents noeuds (on suppose un nombre de N peers) de mani`ere `a ce que chaque peer poss`ede sa propre portion de l’espace. Ainsi, chaque peer va maintenir une table de routage contenant l’adresse IP des noeuds voisins ainsi que leurs coordonn´ees associ´ees au sein de l’espace permettant alors

`

a cette peer de router un message vers un noeud qui est plus proche de la destination.

Pour un espace de dimension d partitionn´e en n zones, la longueur moyenne d’un chemin lors d’un routage est de ^d₄n^1d sauts et chaque noeud maintient 2d noeuds voisins. Afin de placer la paire ¡Cl´e, Valeur¿, une fonction de hashage uniforme est utilis´ee de fa¸con

`

a faire correspondre la cl´e `a un point de l’espace. Ensuite, dans le but de retrouver la valeur correspondante `a une cl´e, un noeud va utiliser cette mˆeme fonction pour trouver le point P. Si le noeud effectuant la requˆete ou ses voisins ne d´etiennent pas le point P dans leur espace, la requˆete sera alors transf´er´ee au travers le r´eseau CAN jusqu’`a ce noeud.

Comme illustr´e `a la figure3.5, un noeud arrivant dans le syst`eme doit se voir accorder une portion de l’espace. Pour ce faire, le nouveau noeud se connecte aupr`es du noeud de bootstrap<sup>8</sup> qui va lui renseigner de mani`ere al´eatoire un certain nombre de peers. Le nouveau noeud choisira alors dans cette liste une peer qui permettra de transf´erer une requˆete JOIN vers un point al´eatoireP de l’espace. Ce message se verra transf´erer jusqu’au noeud le plus proche en terme de coordonn´ees du pointP qui se verra partager son espace

7Self-organizing.

8Noeud de connexion de fran¸cais.

Fig. 3.5 – CAN : ajout du noeud 7 et partage de la zone appartenant `a 1 en deux

propre en deux avec le noeud joignant. Le nouveau noeud pourra alors cr´eer son ensemble de noeuds voisins.

Lorsqu’un noeud quitte le r´eseau, un noeud voisin le d´etecte et va r´ecup´erer la zone pr´ec´edemment occup´ee. Les voisins vont ´egalement mettre `a jour leur table de routage afin d’´eliminer le noeud qui n’est plus actif.

Chord

Chord [41] utilise le “hashing consistent” [18] afin r´epartir des cl´es entre les diff´erents peers du syst`eme tout en balan¸cant la charge avec une grande probabilit´e (les noeuds re¸coivent plus ou moins le mˆeme nombre de cl´es). De plus, lors de l’ajout ou du d´epart du N<sup>e</sup> noeud, seulement O(<sub>N</sub><sup>1</sup>) des cl´es se verront d´eplac´ees afin de maintenir la r´epartition de la charge. Dans un syst`eme `a N peers, chaque noeud maintient des informations de routage pour seulementO(logN) peers.

La fonction de “hashing consistent” assigne `a chaque noeud ainsi qu’`a chaque cl´e un identifiant dembits qui sera calcul´e par hashage sur base de l’adresse IP pour les noeuds et sur base de la cl´e dans le cas d’une cl´e. Afin d’´eviter au maximum des conflits d’identifiants, la valeur de m se doit d’ˆetre suffisamment grande de mani`ere `a rendre la probabilit´e d’un conflit tr`es petite. L’ensemble des identifiants est ordonn´e sur un cercle modulo 2m qui est

N8's Finger Table

+1 +2 +4 +8 +16 +32

Fig. 3.6 – Chord : “finger table” du noeud N8

identifiant qui suit celui de la cl´e dans le sens des aiguilles d’une montre. Ce noeud sera appel´e le successeur de la cl´e k et est not´e successeur(k). Afin de pr´eserver la r´epartition de la charge lors de l’arriv´ee d’un noeud n, certaines cl´es assign´ees aux successeurs de n doivent ˆetre assign´ee `a n. De mˆeme, lors du d´epart du noeud n, toutes les cl´es assign´ees

`

a n doivent ˆetre r´eparties entre les diff´erents successeurs de n. Le nombre de messages n´ecessaires pour r´etablir le cercle lors de l’arriv´ee ou du d´epart d’un noeud est de l’ordre deO(log²N).

m ´etant le nombre de bits de l’espace d’adressage des identifiants, chaque noeud va maintenir jusqu’`a mentr´ees dans une table de routage appel´ee“finger table”. La i<sup>e</sup> entr´ee de la “finger table” du noeudncontient l’identit´e du premier noeud squi suitn d’au moins 2<sup>i−1</sup>. Autrement dit,s=successeur(n+2<sup>i−1</sup>). Chaque entr´ee de cette table contient l’iden-tifiant du noeud concern´e ainsi que son adresse IP. Il est important que les informations concernant les successeurs soient `a jour. Pour ce faire, Chord ex´ecute p´eriodiquement un algorithme de stabilisation qui va mettre `a jour les pointeurs vers les noeuds successeurs dans la “finger table”.

Le m´ecanisme utilis´e par le noeud n lors d’une requˆete pour trouver le successeur de la cl´eket donc pour connaˆıtre le noeud stockant cette donn´ee est le suivant :nva rechercher

dans sa “finger table” le noeud ayant un identifiant plus proche de celui dek que le sien et lui transf´erer la requˆete. Chord effectue ainsi le routage avec grande probabilit´e enO(logN) dans des conditions standard avec un syst`eme compos´e de N noeuds.

Pastry

Pastry [34] utilise, tout comme la couche de routage Tapestry⁹, le m´ecanisme de routage par pr´efixe afin de d´eterminer les routes emprunt´ees lors de l’envoi de messages. Cette m´ethode, illustr´ee `a la figure 3.7, permet de se rapprocher efficacement de la destination en augmentant, `a chaque saut constituant la route, la longueur du pr´efixe commun `a l’identifiant du noeud courant et `a celui de la destination.

128

Fig. 3.7 – Pastry : Routage par pr´efixe

Cette couche de routage assigne `a chaque noeud ainsi qu’`a tout objet un GUID d’une longueur de 128 bits. Ce dernier est calcul´e pour les noeuds en appliquant une fonction de hashage s´ecuris´ee (telle que SHA-1 [11]) sur l’adresse IP du noeud consid´er´e ou encore sur sa cl´e publique. En ce qui concerne l’identifiant des objets, ce dernier est calcul´e en

9Tapestry [56] ne sera pas d´etaill´e dans ce m´emoire ´etant donn´e sa grande similitude de fonctionnement

appliquant ´egalement une fonction de hashage s´ecuris´ee sur par exemple le nom de l’objet.

Cette assignation d’identifiants permet d’obtenir des GUIDs uniform´ement distribu´es sur l’intervalle de [0 ; 2¹²⁸−1], qui seront ordonn´es sur un cercle de GUIDs tout comme celui de Chord.

En supposant un r´eseau compos´e de N noeuds, Pastry permet de router un message vers le noeud qui est num´eriquement le plus proche d’une certaine cl´e en moins dedlog_BNe sauts et ce, sous des conditions standard (B = 2^b est un param`etre de configuration avec une valeur typique pour b de 4). Un GUID est donc consid´er´e ici comme une s´equence de chiffres en base B. Lors du routage, une peer va transf´erer un message au noeud ayant un identifiant qui partage avec la cl´e un pr´efixe, qui est au moins un chiffre plus long que le pr´efixe partag´e par la cl´e et le noeud courant. Dans le cas o`u un tel noeud n’est pas connu, ce message sera transf´er´e `a un noeud ayant un identifiant partageant un pr´efixe avec la cl´e aussi long que la peer courante mais ´etant num´eriquement plus proche de la cl´e que l’identifiant du noeud courant. Pour ce faire, chaque noeud va maintenir les trois ensembles suivants d´etaill´es par la suite :

– une table de routage, – un leaf set,

– un neighborhood set.

Une table de routage R, illustr´ee `a la figure 3.8, est une table compos´ee de log<sub>B</sub>N lignes compos´ees chacune deB−1 entr´ees. LesB−1 entr´ees se trouvant `a lan^eligne deR correspondent `a des peers ayant leur identifiant (NodeID) qui partage lesnpremiers chiffres de l’identifiant du noeud courant mais qui diff`ere de ce dernier au chiffre n+ 1. Chaque entr´ee composant R contient l’adresse IP de la peer se conformant `a la r`egle pr´ecit´ee et est choisie selon une m´etrique de proximit´e. Le choix de la valeur de b constitue donc un compromis entre la taille de la table de routage de chaque noeud (´egale `a (log<sub>B</sub>N)(B−1)) et le nombre de sauts n´ecessaires lors du routage d’un message (´egal `a log_BN).

Le neighborhood set M est un ensemble constitu´e de couples ¡ NodeId, Adresse IP ¿ de

|M| noeuds proches du noeud local en terme d’une certaine m´etrique de proximit´e (telle que le nombre de sauts IP). Cet ensemble n’est pas utilis´e lors du routage d’un message mais est fort utile afin de maintenir les propri´et´es de localit´e de Pastry.

Le leaf setLest un ensemble de noeuds divis´e en deux parties :|L|/2 noeuds num´eriquement proches ayant leur NodeId plus grand que le noeud courant et|L|/2 noeuds num´eriquement

P=

Préfixes des GUID suivis des nodehandles correspondants n

60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F

n n n n n n n n n n n n

650 651 652 653 654 655 656 657 658 659

n n n n n n n n n n n n n

65A0 65A1 65A2 65A3 65A4 65A5 65A6 65A7 65A8 65A9 65AA 65AB 65AC 65AD 65AE 65AF 0 1 2 3 4 5 6 7 8 9 A B C D E F

Fig. 3.8 – Pastry : Table de routage du noeud ayant un GUID commen¸cant par 65A1. les n correspondent `a des couples ¡ GUID, Adresse IP ¿ symbolisant des noeuds qui devront ˆ

etre utilis´es lors du routage.

proches ayant leur NodeId plus petit que le noeud courant. Le leaf Set est utilis´e lors du routage comme pr´ecis´e ci-dessous. Les tailles deM et deL sont g´en´eralement deB ou 2B.

Le routage d’un message s’effectue en suivant l’algorithme ci-dessous :

1. Tout d’abord, le noeud recevant le message v´erifie si la cl´e se trouve dans l’´etendue du leaf set. Si c’est le cas, le message est directement transf´er´e vers le noeud de des-tination, soit le noeud appartenant au leaf set et dont l’identifiant est le plus proche de la cl´e.

2. Dans le cas contraire, la table de routage devra ˆetre utilis´ee et le message sera transf´er´e au noeud partageant un pr´efixe avec la cl´e d’une longueur plus grande d’un chiffre qu’avec le noeud courant. Dans certains cas, il est possible que l’entr´ee appropri´ee de la table de routage soit vide ou non-joignable. Dans ce cas, le message est transf´er´e vers un noeud qui partage un pr´efixe avec la cl´e aussi long qu’avec le noeud courant mais qui est num´eriquement plus proche de la destination que ce der-nier.

A moins que |L|/2 noeuds adjacents du leaf set ne souffrent de d´efaillances

simul-dynamique de noeuds pouvant joindre le r´eseau ou le quitter de mani`ere brutale `a n’im-porte quel instant. Afin de joindre le r´eseau, un noeud X va contacter une peer A proche en terme de localit´e et lui envoyer un message JOIN ayantX pour destination. Ce message sera alors rout´e de fa¸con normale entre diff´erents noeuds jusqu’`a arriver au noeudZ qui est num´eriquement le plus proche. L’ensemble des noeuds travers´es entreAetZ vont envoyer

`

a X des parties de tables de routage et de leaf set, de fa¸con `a ce que ce dernier puisse s’initialiser.

Dans le cas d’une d´efaillance d’un noeudIappartenant au leaf set d’une peerK, celle-ci va contacter un noeud A num´eriquement proche de I. A va alors envoyer en r´eponse une copie de son Leaf Set qui sera utilis´e par K pour r´eparer son leaf set. La r´eparation de la table de routage se fait lors de la consultation de cette derni`ere durant le routage d’un message.

Communication de groupe

4.1 Introduction

Le multicast, ou diffusion de groupe, est un mode de communication qui est apparu afin de r´epondre au probl`eme de surcharge d’un r´eseau engendr´e par une communication d’une station vers un groupe de stations int´eress´ees. En effet, ce genre de communication n´ecessitait d’envoyer un mˆeme message `a chaque membre du groupe de destination, en-gendrant ainsi un flux de donn´ees beaucoup plus important qui va encombrer le r´eseau. Ce type de communication utilise donc le principe de communication unicast qui est illustr´e

`

a la figure 4.1. Ainsi, afin d’´eviter cette surcharge, la communication multicast permet de n’envoyer qu’un seul message vers un groupe de processus int´eress´es, l’appartenance au groupe ´etant g´en´eralement transparente pour l’exp´editeur du message. Il est `a noter que ce type de communication est souvent confondu avec la communication broadcast qui permet d’envoyer un message d’un processus vers tous les processus d’un r´eseau, tandis que le multicast le permet vers certains processus. Un autre mode de communication possible au sein d’un syst`eme distribu´e est la communication anycast qui permet d’envoyer un message vers un seul membre d’un groupe, g´en´eralement le plus performant ou le plus proche.

Les applications utilisant le mode de communication multicast sont nombreuses et couvrent un grand nombre de domaines. Parmi celles-ci, on peut citer les applications sui-vantes :

Emetteur Destination 4

Destination 3

Destination 2 Destination 1

Données envoyées = 4 x taille d’un seul message

Fig. 4.1 – Envoi d’un mˆeme message vers quatre destinations

• le tableau partag´e¹ permettant `a plusieurs intervenants de modifier simultan´ement une zone d’´ecriture ou de dessin, facilitant ainsi par exemple la collaboration d’em-ploy´es d’une mˆeme entreprise se trouvant aux quatre coins du monde,

• les applications de chat,

• les conf´erences Audio/Vid´eo,

• la communication avec un groupe de serveurs,

• la r´eplication de donn´ees,

• les jeux interactifs `a grande ´echelle sur Internet,

• les bases de donn´ees distribu´ees, ...

Apr`es avoir introduit les concepts du IP-multicast, ce chapitre se focalisera sur le mul-ticast de type applicatif impl´ement´e dans un environnement peer-to-peer tout en essayant de mettre en ´evidence ses avantages par rapport au IP-multicast.

1Shared whiteboards.