Propositions ` a topologie annulaire

Les donn´ees r´ef´erenc´ees par une DHT doivent ˆetre accessibles de mani`ere fiable et celle-ci doit garantir un niveau de performance donn´e. Pour cela, le processus de maintenance, ex´ecut´e de mani`ere asynchrone par chaque pair, vise `a v´erifier r´eguli`erement que les entr´ees des tables de routage sont correctes, `a savoir, qu’elles sont en accord avec les propri´et´es de la structure topologique, et que les pairs r´ef´erenc´es sont joignables. Ces op´erations de maintenance doivent, en outre, n´ecessiter le minimum de ressources de traitement local et de communication.

Dans cette section, nous avons pr´esent´e le principe g´en´eral des DHTs ainsi que leurs pro-pri´et´es. Au niveau des implantations, comme le montre la figure 3.2, il existe plusieurs grandes classes de DHTs qui se diff´erencient principalement par le mod`ele topologique sur lequel elles reposent. En outre, au sein de chaque classe, il existe de nombreuses propositions de DHTs. Dans la suite de ce chapitre, nous allons pr´esenter une DHT majeure pour chaque classe4. Nous nous attarderons en particulier sur Chord [153] et Pastry [137] qui sont des infrastructures sur lesquelles nous avons travaill´e.

Hypercube Anneau Plaxton Butterfly De Bruijn Small world Topologie non structurée CAN Chord Viceroy Koorde Pastry Tapestry P-Grid DMBN Symphony ^Freenet Kademlia IHOP Hypercup Yappers D-Trie D2B Distance Halving Pancake ^Arbre ODRI Ulysses Bamboo

Fig.3.2 – Taxonomie topologique des diff´erentes DHTs. Les familles sont inscrites en caract`eres gras et les propositions en italique.

3.3 Propositions `a topologie annulaire

Organiser les pairs selon un anneau est envisag´e dans plusieurs travaux. Tout d’abord dans Chord [153] qui propose d’organiser les pairs selon un anneau simple. Ensuite, dans Viceroy [103] qui est une version am´elior´ee de Chord, reposant les r´eseaux Butterfly. Enfin, dans Kademlia [108] qui repose sur la fonction ou exclusif. On peut noter que de nombreuses DHTs utilisent de mani`ere plus ou moins directe l’organisation des pairs selon un anneau. C’est par exemple le cas de CAN [124] dont la topologie est un hypercube torique, ou de Pastry [137] qui utilise un anneau pour finaliser son routage. N´eanmoins, nous avons choisi de ne pas d´etailler ces infrastructures

4

Nous laisserons en marge les propositions qui ne pr´esentent qu’un principe, comme par exemple IHOP [123] ou ODRI [102] et celles qui nous semblaient secondaires comme Ulysses [94] ou Kelips [70].

dans cette section mais plutˆot dans celle qui correspond au mieux `a leur mod`ele topologique g´en´eral. Nous pr´esentons ici Chord [153] et Viceroy [103].

3.3.1 Chord

Chord [153] est un protocole de recherche P2P pour les applications Internet : pour une cl´e donn´ee, Chord y associe un pair. Chord est d´eploy´e dans plusieurs applications : tout d’abord, dans CFS⁵ [30] qui est un syst`eme de fichiers distribu´e `a l’´echelle de l’Internet, ensuite dans ConChord [6] qui utilise CFS afin de fournir une infrastructure distribu´ee pour la d´elivrance de certificats de s´ecurit´e SDSI⁶ et enfin dans DDNS⁷ [29] qui propose une implantation P2P du DNS⁸.

Le protocole Chord

Chord repose sur une topologie en anneau ; un pair Chord a la connaissance de son pr´ed´eces-seur et de son suivant. Une fonction de hachage r´eguli`ere g´en`ere un identifiant pour chaque pair `

a partir de son adresse IP. Ensuite, chaque pair est plac´e dans l’anneau de mani`ere `a ordonner les identifiants par ordre croissant. Ainsi, chaque pair d’identifiant n est responsable de l’intervalle de cl´es ]precedent(n), n] . Lookup(K54) N1 N8 N14 N21 N32 N38 N42 N48 N51 N56 _K54 N1 N8 N14 N21 N32 N38 N42 N48 N51 N56 Lookup(K54) N1 N8 N14 N21 N32 N38 N42 N48 N51 N56 _K54 +1 +2 +4 +8 +1 6 +32 Finger table N8+1 N14 N8+2 N14 N8+4 N14 N8+8 N21 N8+16 N32 N8+32 N42 (a) (b) (c)

Fig. 3.3 – Extrait de [153]. (a) Acheminement d’une requˆete par parcours de l’anneau. (b) D´efinition des fingers d’un pair. (c) Acheminement d’une requˆete en utilisant les fingers.

Pour un pair donn´e, la simple connaissance de son pr´ec´edent et de son suivant n’est pas suffisante pour garantir une bonne performance de l’anneau, notamment en termes de nombre de sauts par requˆete. La figure 3.3.a illustre ce type de probl`eme avec un anneau contenant 10 pairs avec une plage d’adressage comprise dans l’intervalle [0, 64[. On peut constater que le routage d’un requˆete d’un pair de cl´e N8 `a destination de la cl´e K54 necessitera 8 sauts. Afin de pallier ce probl`eme, pour un espace de cl´es compris dans l’intervalle [0, 2m[, chaque pair n se voit dot´e d’une entr´ee vers les pairs, appel´es fingers, de cl´e suivant(n + 2i−1) avec 1 ≤ i ≤ m. Ainsi, le nombre maximum de pairs parcourus pour acheminer une requˆete s’exprime en termes de O(log(N )). La figure 3.3.b pr´esente la table de routage du pair N8 muni de fingers et la figure

5

Collaborative File System

6

Simple Distributed Security Infrastructure

7

Distributed Domain Name System

8

3.3. Propositions `a topologie annulaire

3.3.c montre que la mˆeme requˆete de cl´e K54 est cette fois achemin´ee en 3 sauts. La table de routage d’un pair Chord compte ainsi O(log(N )) entr´ees.

Insertion, d´epart et maintenance

L’insertion d’un nouveau nœud dans une communaut´e se fait par la simple recherche de son suivant dans l’anneau. C’est ensuite le processus de maintenance qui, ex´ecut´e r´eguli`erement, va prendre en charge le maintien de la coh´erence des tables de routage des pairs concern´es par l’arriv´ee du nouvel ´el´ement. En effet, `a intervalles r´eguliers chaque nœud v´erifie la validit´e des informations d´etenues dans sa table de routage `a savoir : son suivant et les fingers.

La v´erification de son suivant s’effectue en lui demandant quel est son pr´ec´edent. Si la r´eponse est soi-mˆeme, le suivant est correct. Si le r´esultat est l’identifiant d’un nœud situ´e entre soi et son suivant, il devient alors le nouveau suivant, et est notifi´e que le nœud courant est le nouveau pr´ec´edent.

La v´erification des fingers est similaire `a la construction de la table et consiste `a rechercher pour chaque entr´ee le nœud correspondant d’identifiant suivant(n + 2i−1), avec 1 ≤ i ≤ m. La table est mise `a jour si jamais un pair diff´erent des pairs actuels est trouv´e. Par le biais de ces v´erifications r´eguli`eres, Chord garantit le maintien de la coh´erence de l’anneau.

Dans le cas d’un d´epart de nœud, c’est le processus de maintenance qui permet la mise `a jour des informations maintenues par les pairs. En outre, afin de limiter les ´echecs de requˆetes survenant dans l’intervalle de temps situ´e entre la disparition d’un nœud et l’ex´ecution de ce processus, chaque nœud maintient une liste de suivants, qui peuvent ˆetre utilis´es alternativement au suivant d´efaillant.

3.3.2 Viceroy

Viceroy [103] est une proposition de DHT inspir´ee de Chord mais qui y ajoute de nombreuses am´eliorations. La principale consiste `a construire une topologie `a multi-anneaux o`u chaque pair pr´esente une connectivit´e constante. En effet, si dans Chord, la connectivit´e des pairs s’exprime en log(N ), dans Viceroy, elle est constante et ´egale `a 7. Par ce biais, les coˆuts d’insertion d’un pair dans la communaut´e, et de mise `a jour des informations maintenues sont maˆıtris´es. En outre, les performances sont similaires `a celles propos´ees dans d’autres DHTs, avec un nombre moyen de sauts qui s’exprime en O(log(N )) pour le routage des messages.

Le protocole Viceroy

Chaque pair Viceroy est muni d’un identifiant al´eatoire appartenant `a l’intervalle [0, 1[ et d’un niveau l tel que l est d´etermin´e al´eatoirement dans l’intervalle [1, log(N )[. La figure 3.4 illustre un exemple de topologie Viceroy contenant une trentaine de pairs r´epartis sur 4 niveaux qui forment quatre anneaux distincts.

Chaque pair d’identifiant id et de niveau l maintient des connexions vers 7 autres pairs. Tout d’abord, vers les pairs pr´ec´edents et suivants sur l’anneau de mˆeme niveau. Ensuite, vers les pairs pr´ec´edents et suivants sur l’anneau de r´ef´erence, `a savoir celui de niveau 1. Enfin, les trois derni`eres connexions permettent des passages entre les niveaux et consistent en deux liens vers le niveau inf´erieur qui r´ef´erencent les pairs d’identifiant suivant_l+1(id) et suivant_l+1(id +₂¹l) et un lien vers le niveau sup´erieur vers un pair d’identifiant suivant_l−1(id). Sur la figure 3.4, on a repr´esent´e les liens maintenus par les pairs d’identifiant 0, 14 et 0, 35. Par souci de clart´e, les liens vers le pair de niveau inf´erieur ne sont pas indiqu´es. On constate que les liens entre niveaux,

appel´es liens Butterfly permettent de parcourir de grandes distances dans la communaut´e. C’est par exemple le cas du pair O, 14 qui r´ef´erence un pair d’identifiant proche de 0, 75.

Etant donn´e cette topologie, le routage d’un message s’effectue en trois ´etapes. La premi`ere consiste `a remonter les niveaux jusqu’`a atteindre un nœud de niveau 1. Ensuite, la seconde effectue la redescente des niveaux en utilisant les liens Butterfly de courte ou longue distance. Enfin, lorsqu’aucun pair de niveau inf´erieur ne permet de se rapprocher plus de la cible, les liens intra-anneau sont utilis´es jusqu’`a l’arriv´ee `a destination. De cette mani`ere, avec une tr`es forte probabilit´e, les messages sont rout´es en O(log(N )) sauts.

0 0,5 0,25 0,75 Niveau 1 2