Laboratoire de l’Informatique du Parallélisme

École Normale Supérieure de Lyon

Unité Mixte de Recherche CNRS-INRIA-ENS LYON-UCBL n ^o 5668

Déouverte de servies pour les grilles de

alul dynamiques large éhelle

CédriTedeshi

Nov2006

Researh Report N o

2006-44

École Normale Supérieure de Lyon

46 Allée d’Italie, 69364 Lyon Cedex 07, France

Téléphone : +33(0)4.72.72.80.37

Télécopieur : +33(0)4.72.72.80.80

Adresse électronique :

lipens-lyon.fr

large éhelle

CédriTedeshi

Nov 2006

Abstrat

Within omputationalgrids,some servies(softwareomponents, linear

algebralibraries,et.) aremadeavailablebysomeserverstosomelients.

In spite of the growing popularity of suh grids, the servie disovery,

although eient in many ases, does not reah several requirements.

Among them, the exibility of thedisovery and its eieny on wide-

area dynami platforms are two major issues. Therefore, it beomes

ruialtoproposenewtoolsopingwithsuhplatforms. Emergingpeer-

to-peertehnologiesprovidealgorithmsallowingthedistributionandthe

retrievalofdataitemswhileaddressingthedynamiityoftheunderlying

network.

We studyinthis papertheserviedisoveryinapurepeer-to-peerenvi-

ronment. Wedesribeanewtrie-basedapproahfortheserviedisovery

that supports rangequeries and automati ompletion of partialsearh

strings,whileprovidingfault-tolerane,andpartiallytakingintoaount

the topologyofthe underlyingnetwork. Wevalidatethis approahboth

by analysis and simulation. Traditional metris onsidered in peer-to-

peer systems exhibits interesting omplexities within our arhiteture.

The analysis'results areonrmed bysome simulationexperimentsrun

using severalgrid'sdata sets.

Keywords: Serviedisovery,omputationalgrids, peer-to-peer, prextrees

Résumé

Dans les grilles desserveurs orent desservies aux lients an de réa-

liser des aluls. Avant de pouvoir les utiliser, les lients doivent être à

mêmedelesretrouver.Bienquelesdiérentessolutionsproposéesdepuis

l'émergenedesgrillessoienteaessurdesplates-formesrelativement

statiques et de petite éhelle, elles ne sont plus en adéquation ave la

nature dynamiqueet à large éhelle des grillesfutures.Pour de tels en-

vironnements denouveauxoutils doivent être proposés,notamment des

méanismes pour ladéouverte de servies,qui devront être exibles et

passer à l'éhelle dans des environnements dynamiques. Nous étudions

dans e papier ladéouverte de servies pour des grilles de alul pair-

à-pair. Nous proposons une nouvelle arhiteture basée surun arbre de

plus longpréxes.

Mots-lés: Déouverte de servies,grillesde alul,pair-à-pair, arbres de préxes

1 Introdution

Ces dernières années, les grilles onnetant des ressoures distribuées sont devenues une al-

ternative eae pour résoudredesproblèmes de grandetaille. Toutefois, ledéploiement des

grilles de alul est une tâhe diile et de nombreux problèmes sont à prendre en onsid-

ération tels quelaséurité,l'ordonnanement, lagestiondesressoures, et. Danset artile

nousnous intéresseronsà ladéouverte de servies.

Lesserviesd'unegrillesontunensembledeomposantslogiiels(bibliothèquesdealul,

exéutables, et.) que des serveurs mettent à la disposition des lients. Depuis l'émergene

des grilles, diérents méanismes de déouverte des servies ont été utilisés. Ces outils tra-

ditionnels, eaespour lesplates-formes relativement statiquesetà petiteéhelle etfondés

sur des méanismes entralisés ou semi-entralisés, perdent leur eaité dans des environ-

nements large éhelle où les n÷uds peuvent quitter le réseau à tout instant sans prévenir.

Iamnithiet Foster ont réemment suggéré que les grilles, qui fournissent une infrastruture

pour le partage de ressoures, mais perdent leur eaité sur des plates-formes dynamiques

grandeéhelle,gagneraient às'inspirer des méanismespair-à-pair [6 ℄. Lestehnologies pair-

à-pairfournissent desalgorithmes permettant lareherhe d'objets. Parmi elles,les tablesde

hahage distribuées (DHT) [13, 15 ℄ ont été initialement développées pour des systèmes très

large éhelle tel que lepartage de hiers surInternet. Bien queles DHT passent à l'éhelle

danslesens où une reherhe demande un nombrede sauts et une taille de table de routage

logarithmiques en la taille du système et sont tolérantes aux pannes, elles présentent deux

défautsmajeurs. D'abord,leplaement desn÷udsdansleréseaulogiquenetientpasompte

de la topologie physique du réseau, e qui entraîne une perte importante des performanes.

Ensuite, leurs méanismes de déouverte sont très rigides, puisqu'ils ne permettent que des

reherhes exates, sur une lef préise. La setion 2 dérit les travaux atuels herhant à

résoudreesproblèmes.

Dansnotre approhe,les serviessont préinstalléssurles serveurset leslients herhent

à les déouvrir. Un servie est dérit par un ensemble d'attributs, par exemple le nom du

servie, le proesseur et le système du serveur qui le fournit. Nous déoupons le problème

selondiérentsritères.

Tout d'abord, nous souhaitons supporter la omplétion automatique des haines de

reherhe partielleet les requêtes sur des intervalles de lefs. Onremarquera que es deux

fontionnalités sont similaires. Une autre fontionnalité importante est la reherhe multi-

ritères. Enn, pour faire fae aux besoins des environnements pair-à-pair, il est ruial

d'intégrer de latolérane aux pannes pour assurer la ohérene du routage si des n÷uds

quittent le réseau. Enn, pour éviter de grandes latenes lors des requêtes et ainsi rendre

l'arhitetureinutilisableàlargeéhelle,ilestimportantquelatopologielogiquetienneompte

delaloalité physiquedu réseausous-jaent.

Notre ontribution, la Table de Plaement Lexiographique Distribuée (TPLD) est une

nouvelle arhiteture qui utilise une approhe pair-à-pair basée sur un arbre de plus long

préxespour ladéouvertede serviesen fournissant les méanismesnéessaires à lamiseen

÷uvredesfontionnalitésdérites au-dessus.

Dans la setion suivante, nous donnons un rapide résumé de l'état de l'art dessolutions

pour des reherhes omplexes dans les systèmes pair-à-pair et pour la prise en ompte de

la topologie du réseau physique (on parle aussi de loalité). Ensuite, après avoir préisé la

modélisation des servies, nous exposons le prinipe général de la TPLD setion 3. Nous

validation analytique de nos travaux qui est aompagnée par nos résultats par simulation

dansla setion7.

2 Etat de l'art

Comme nous l'avons déjà vu, les deux prinipaux inonvénients atuels des DHT sont la

rigidité de leur reherhe etlanon prise en ompte delatopologie du réseau sous-jaent.

La formulationde solutions pour l'injetion de loalité physique dans leréseau logique a

engendré unelittératureimportante[20,7,17,13,19,18 ℄. Toutefois, estravauxs'appliquent

à des topologies en anneau et en tore, leur exploitation dans un arbre de préxe n'est pas

trivial.

L'autre inonvénient majeurdesDHTest leurméanismede reherhe rigidequiestbasé

sur unelef unique. Une sériedetravauxinitiée par [9℄ apourbut de supporter desrequêtes

omplexes dansdes systèmes pair-à-pair struturées. INS/Twine [3℄ permet une desription

semi-struturée (en XML) des objets reherhés. [16 ℄ étend les opérations traditionnelles

des bases de données dans les systèmes pair-à-pair. Squid [14℄ permet desreherhes multi-

ritères et la omplétion automatique des haînes de reherhe. Les travaux d'Andrzejak

et Xu [1 ℄ par exemple supportent les reherhes uniritères sur un intervalle de valeurs en

utilisant les ourbes de remplissage de l'espae de Hilbert. Construit au-dessus de plusieurs

DHT,SWORD[11℄estunservied'informationsupportantlesrequêtesmulti-ritères surdes

intervallesdont lebut estla déouverte deressoures dealul.

Plus prohe de notre arhiteture, diérents travaux se basent sur des arbres lexi-

ographiques, dont le parallélisme permet une latene pour les requêtes sur un intervalle

logarithmique en lataille de l'arbre. Skip graphs [2℄ est une struture de données distribuée

fondée sur les skip list, où haque ressoure est un n÷ud du graphe. PHT [12℄ onstruit

un arbre lexiographique deslefs au-dessus d'uneDHT, dont les omplexitésse multiplient.

Nodewiz[4 ℄s'appuiedemêmesurunarbrelexiographique, maisseplaesuruneplate-forme

où les n÷udssont onsidérés stables. P-Grid[5℄ onstruit demême unarbre lexiographique

ave l'ensembledel'espaedeslefs. Une aratéristiqueommune àtoutesesapprohesest

qu'elles ne prennent pasen ompte latopologie physique de laplate-forme. Nousomparons

es approhes ave notrearhiteture danslasetion6.

L'idée lef de la TPLD est de onstruire dynamiquement un arbre logique des servies,

et de le plonger dans le réseau physique, grâe à un méanisme distribué omme une DHT.

Il est toutefois important de dissoier plongement et routage des requêtes dans l'arbre qui

se fait indépendamment, ontrairement à [12℄. Nous utilisons un méanisme de répliation

pour prévenir les déonnexions de n÷uds etnous nousadaptons partiellement à latopologie

physique.

3 Table de Plaement Lexiographique Distribuée

Nous faisonsii une desriptiongénéralede notre ontribution. Il estpour elanéessaire de

mieuxdénirequeseraunserviedanslaTPLD.Lesserviessonttraditionnellementdérits

par un ensemble d'attributs. On onsidère les attributs suivants: 1 - Le nom du servie,

sous lequel il est onnu par les utilisateurs. Par exemple DGEMM de la bibliothèque BLAS. 2

- Le proesseur du serveur, par exemple pour desproblèmes deodage des données. 3 -

Figure1: Exempledeonstrution del'arbre: Lesn÷udsoloriésreprésentent desn÷udsaux

lefs réelles. (1)Unservie DGEMMest délaré. (2) UnservieDTRSM estdélarénéessitant la

réation du n÷udà la lefvirtuelle D, plus long préxé desdeux lefs réelles. (3)Un servie

DTRMMest délaré. A droite,un exempled'arbre répliqué.

loalisationduserveurpourdesquestionsdeonaneoudeproximitéavelelient. Pour

failiter l'autoomplétion des loalisations, on spéiera les mahines en notation inversée,

par exemple, fr.grid5000.* si l'on veut une mahine de la grille Grid'5000, où enore edu.*,

et. L'exemple i-dessous illustre la desription d'un servieDGEMM fourni par un serveur de

Grid'5000dontlesystèmed'exploitationestuneDebianetleproesseurunPowerPC.Chaun

desattributs estassoiéàlaloalisationduserviepourformerlesouples

(clef, valeur)

^(ii,

àdroite)qui serontdélarés etindexésdansla TPLD.

Servie={ DGEMM,

Linux Debian 3.0,

PowerPC G5,

fr.grid5000.lyon }

(DGEMM, lyon.grid5000.fr)

(Linux Debian, lyon.grid5000.fr)

(PowerPC G5, lyon.grid5000.fr)

(fr.grid5000.lyon, lyon.grid5000.fr)

En terme de fontionnalités, la TPLD indexeet reherhe desréférenes de servies sous

forme de ouples

(clef, valeur)

^{. Elle fournit} l'autoomplétion des haînes de reherhe par- tielles. Par exemple,un lient peutdéouvrir les serviesBLASpréxés par lahaîneDTR. Il

reevra tous les serviesDTRMV, DTRSV,DTRMM etDTRSM.La TPLD s'appuiesurun plaement

lexiographique desattributs dansl'arbre.

L'arhiteture logiquede laTPLD sont desarbres lexiographiques réduits, aussiappelés

arbres deplus long préxe. L'entité de basede laTPLDest unn÷udde esarbres,quenous

nommerons n÷udlogique. Unn÷udlogiquestoke lesréférenesdesserviesdélaréspar les

lients. L'identiant d'unn÷udorrespondà lalefdesserviesqu'ilsstokent. Ondistingue

deux typesde lefs. Deslefs réelles qui orrespondent à desservies réellement délarés. On

remarquera que les feuilles de l'arbre orrespondent à des lefs réelles. Des lefs virtuelles

qui sont néessaires à laonstrution de l'arbre. Notons qu'une lefvirtuelle est laraine du

sous-arbre dont les n÷uds ont pour identiant des lefs préxées par ette lef virtuelle. La

gure1déritlaonstrutiondynamiqued'unarbrequireçoitladélarationdetroisservies.

Les n÷uds de l'arbre logique doivent être distribués sur les n÷uds physiques du réseau

physiquesous-jaent. Onappelleralesn÷udsphysiquesdespairsquivonthéberger,sousforme

de proessus un ou plusieurs n÷uds logiques. Ce plongement peut-être réalisé de plusieurs

manières. Un exemple distribué est d'utiliser une DHT et de plaer un n÷ud logique sur le

n÷ud physique qui orrespond au hahage de l'identiant du n÷ud physique. Enn, on se

plae dans un environnement dynamique. La TPLD ore un méanisme de répliation des

arbresde préxes pour assurerle routage enas dedépart de pairs. Par ailleurs,on utilisera

sous-jaent.

Algorithme 3.1 Insertionetplongement (gauhe), répliation etloalité(droite)

Constants:

loc

^{:loallogialnode}

loc.ID

^:IDof

loc

Variables:

loc.children

^{:setofhildrenof}

loc loc.parent

^:parentof

loc

loc.host

^{:addressofthepeerhosting}

loc pref ix

^:string

pref ixP arent

^:string

UponRECEIPTof<logReq,

ID

^>

pref ix

^:=COMMONPREFIX(

ID

^,

loc.ID

⁾

if(SIZEOF(

pref ix

^)=SIZEOF(

loc.ID

^)=SIZEOF(

ID

^))then

//Nodefound.Storingthenewservie.

elseif(SIZEOF(

pref ix

^)=SIZEOF(

loc.ID

^))then

if(

∃f ∈ loc.children |

^SIZEOF(COMMONPREFIX(

f.ID

^,

ID

⁾⁾

>SIZEOF(

loc.ID

^))then

SEND<logReq,

ID

>TO

f

else//Anode

n

^{isreatedasahildoftheloalnodeandhosted}

n

^:=NEWNODE(

ID

^,

parent = loc.parent

^,

children = ∅

⁾

n.host

^:=GETPEER()

SEND<hostReq,

n

^>TO

n.host loc.children

^+={

n

^}

endif

elseif(SIZEOF(

pref ix

)=SIZEOF(

ID

))then if(

loc.parent = ⊥

^)then

//

loc

^{istheurrentroot}

n

^:=NEWNODE(

ID

^,

parent

^:=

⊥

^,

children

^:={

loc

^})

n.host

:=GETPEER()//butitsparentisreated SEND<hostReq,

n

^>TO

n.host

^//andhosted

loc.parent

^:=

n

else

pref ixP arent

:=COMMONPREFIX(

ID

^,

loc.parent.ID

⁾

if(SIZEOF(

pref ixP arent

^)=SIZEOF(

ID

^))then

SEND<logReq,

ID

^TO

loc.parent

^//goingup

else//Anodeisreatedbetween

loc

^and

loc.parent

n

^:=NEWNODE(

ID

^,

parent

^:=

loc.parent

^,

children

^:={

loc

^})

n.host

^:=GETPEER()

SEND<hostReq,

n

^>TO

n.host

SEND<updateChild,

n

>TO

loc.parent loc.parent

^:=

n

endif endif

else

if(

loc.parent = ⊥

^)and((COMMONPREFIX(

pref ix

^,

loc.parent.ID

⁾

=SIZEOF(prex))then

SEND<logReq,

ID

^>TO

loc.parent

else//

loc

^{andthenewnode}

n

^{aresiblings,theyneedaparent}

p p

^:=NEWNODE(

pref ix

^,

parent

^:=

loc.parent

^,

children

^:={

loc

^})

p.host

^:=GETPEER()

n

^:=NEWNODE(

ID

^,

parent

^:=

p

^,

children

^:={

loc

^})

SEND<hostReq,

p

>TO

p.host

SEND<hostReq,

n

^>TO

n.host

SEND<addChild,

n

>TO

p loc.parent

^:=

p

endif

endif

Constants:

loc

^:theloalnode

k

^{:repliationfator}

Variables:

loc.children

^{:setofhildrenof}

loc n.R

^{: setofrepliasofthenode}

n

//Ontherootonly

//Repliatingtheroot,periodially

k ^′

:=GETNBREPLICAS(

loc

⁾

while

k ^′ < k

^do

p

^:=GETPEER()

SEND<hostReq,

loc

^>TO

p k ^′

⁺⁺

forall{

f ∈ loc.children

^}do

//Informingmyhildrenoftheirnewparent

SEND<addParent,

p

^>TO

f

done

done

loc.R

^+={

p

^}

//Launhingtherepliationinthetrie

SEND<sanReq>TO

loc

//Oneverynode

UponRECEIPTof<sanReq>

forall{

f ∈ loc.children

^}do

k ^′

:=GETNBREPLICAS(

f

) while

k ^′ < k

do

p

^:=GETPEER()

SEND<repliationReq,

p

^>TO

f f.R

^+={

p

^}

done

next

^:=GETBESTREPLICA(

f.R

⁾

//Launhthesaninthissubtrie

SEND<sanReq>TO

next

done

4 Constrution et maintenane de la TPLD

4.1 Constrution et plongement dynamique de l'arbre

Nous donnons ii une idée de l'algorithme d'insertion d'un servie délaré sous la forme

(

clef

⁼

c

^,

valeur

⁼

v

^{). Leserveurenvoieunerequête}d'insertiondesonservieàunn÷udquel- onque de l'arbre (dont il obtient la référene par un méanisme extérieur). La requête est

ensuiteroutéeselonlalef

c

^{. Chaquen÷ud,surréeptiondelarequête,applique}l'algorithme suivant,en distinguant quatreas possibles:

c

^{est égal à l'id du n÷ud loal :}

c

^{est don déjà présente dans l'arbre, le n÷ud loal}

stoke

v

^.

c

^{est préxé par l'id du n÷ud loal: len÷udherhe alorsparmi sesenfantsunn÷ud}

dont l'id partage ave

c

^{plus de aratères que lui-même. Si un tel n÷ud existe, la}

requête lui est transmise, sinon,

c

^{donne lieu à la réation d'un nouveau n÷ud ls du}

n÷ud loal.

l'id du n÷ud loalest préxé par

c

^{: sil'iddupèredun÷udloalpréxe}

c

^ouestégal

à

c

^{,larequêtedoitremonterdansl'arbreetesttransmiseaupèredun÷udloal. Sinon,}

c

^{donne lieu àlaréation d'unn÷udentre len÷udloal etsonpère.}

Défaut : sile n÷udloal n'est paslaraine etque l'identiant de sonpère estégal à ou

préxe lepréxe ommun de

c

^{etdu n÷udloal, larequête esttransmise au pèredu}

n÷ud loal. Sinon, le n÷ud loal et

c

^{sont des lefs s÷urs mais leur père doit être de}

même réé. Deuxn÷udssontalors réés,unn÷udd'id

c

^{etlepèredun÷udloaletdu}

nouveau n÷uddont l'idest leurplus longpréxe (éventuellement lahaîne vide).

Nous disutons ii brièvement omment plonger les n÷uds logiques sur les pairs. Une

approhe simpleest d'utiliser un répertoire entral supposé stableauquel haque mahine se

délareetàlaquelleonfaitappellors delaréationd'unn÷udlogiquepourl'héberger. Pour

une arhiteture totalement déentralisée, une solution est de struturer le réseau physique

ave une DHT etd'utiliser la fontion dehahage de laDHT pour plaer les n÷udslogiques

enappliquant lafontion dehahage delaDHT surlesidentiantsdesn÷uds del'arbre. Un

problèmede répartition de la harge apparaît. En eet, l'utilisation d'une DHT garantira la

distributionprobabilisteuniformedesn÷udssurlespairs. Cependant,lahargedetravailsera

également distribuée sous deux onditions habituellement admises dans les DHT. La harge

des n÷uds logiques d'une part et la apaité des pairs doivent être homogènes. La harge

d'unn÷uddépend de lapopularitédes serviesqu'ilsstokent etde sahauteurdansl'arbre.

En eet, plus un n÷ud sera prohe de la raine, plus la proportion de requête qu'il devra

router sera importante. Nous ne traiterons pas ii spéiquement e sujet et onsidérons la

répartition de la harge eetuée au niveau de la DHT qui a donné lieu à une importante

littérature [8, 10 ℄. Adapter le fateur de répliation loalement en fontion de la harge et

répartirles requêtes surhaque répliaest également une solution.

Le pseudo-ode de gauhe de l'algorithme 3.1 détaille le traitement d'une requête

d'insertion. La fontion COMMONPREFIX retourne le plus long préxe de deux haînes.

La fontion NEWNODE rée un nouveau n÷ud logique. La fontion GETPEER appelle le

méanisme deplongement (DHTpar exemple)etretourne laréférened'unpairhoisipar le

méanisme de plongement. La requête hostReq est envoyée au pair hoisi pour héberger un

n÷ud logique nouvellement réé. Les requêtes updateChild etaddChild sont envoyées aux

n÷uds onernés par un hangement dansles référenes vers leurs ls. Le ode exéuté sur

réeption de esmessagesn'est pasdétaillé artrivial.

4.2 Tolérane aux pannes et prise en ompte de la loalité physique

Le routage logique est maintenant xé. Pour faire fae à la dynamiité du réseau, nous

adoptons un méanisme de répliations de l'arbre pour éviter la perte de n÷uds ou de liens

rendantleroutageimpossible. Lefateurderépliation

k

^{,indiquelenombredepairsdistints}

sur lesquels haque n÷ud doit être présent, omme illustré sur la gure 1 pour

k = 2

^{. Pour}

prendre en ompte la loalité physique dans l'arbre, on herhe à minimiser les temps de

ommuniation dansl'arbre répliqué. Nousdevonsprendreenompte diérentes ontraintes.

Dans notre arbre, haquelien a une sémantiquedont une instaneau moinsdoit être gardée

dans l'arbre, e qui rendle problème diérent d'un problème lassique d'arbre ouvrant. De

plus, pour garder une route optimale danslesens physique du termesurhaque n÷udvers

haque n÷ud de l'arbre, il est néessaire de garder une table de routage de taille linéaire en

la taille de l'arbre non répliqué, e qui serait néfaste au passage à l'éhelle. L'optimalité ne

pouvant être atteinte sans ette ondition, nous optons pour une solution raisonnable basée

surune heuristique gloutonne. Chaquen÷udvadéterminerpourhaun deses lslogiquele

répliaquiminimiseàuninstantdonnéletempsdeommuniationavelui. Cetteheuristique

est omplètement intégrée à l'algorithme de répliation et ne modie ni la omplexité de

l'algorithme nilaomplexité dela taillede latable deroutage.

Le proessusde répliationave adaptation à latopologie physique,déritpar le pseudo-

ode de droite de l'algorithme 3.1 et qui est illustré par la gure i-dessous est initié péri-

odiquement par l'unedes rainesde l'arbre(sur lagure, iln'y ena qu'une (1)). Lesraines

de l'arbre et seulement les raines forment un réseau omplet, haque raine onnait don

l'ensemble des raines. Un algorithme simple d'exlusion mutuel prévient l'initialisation de

l'algorithme par plusieurs raines en même temps. La raine élue ommene par déterminer

le nombre de raines joignables, mettons

k ^′

^{. La raine lane don la répliation} d'elle-même

k − k ^′

^{fois en obtenant}

k − k ^′

^{pairs eten envoyant à haun de espairs sapropre struture}

de n÷ud logique. Une fois la raine répliquée, la raine initie la répliation dans l'arbre en

s'envoyant àlui-même une requêtesanReq (2).

Surréeptiond'unerequêtesanReq,unn÷udexéutelepseudo-odedétailléparlapartie

ommune àtouslesn÷udsdupseudo-odededroite del'algorithme3.1. Surréeption, don,

unn÷udtraiteseslsunpar un. Pour haun d'eux,ilteste lenombrederéplias joignables

et demande à l'un d'eux d'envoyer sa struture de n÷ud logique vers un nombre de pairs

néessaires pour atteindre

k

^{via la requête} repliationReq. Il détermine ensuite parmi les réplias de e ls le pair qui minimise le temps de ommuniation ave lui (par la fontion

GETBESTREPLICA)etenvoieàl'éluunerequêtesanReqand'initierlarépliationdansle

sous-arbredeelslogique. Ainsi,déterminélemeilleurréplialoalementpourhaquelsa

deuxfontions: déterminerlepair/répliaquireprésenteraelsdansl'arbreouvrant(etqui

sera ensuiteutilisé pour router les requêtes) et d'élire le pair/réplia qui lane la répliation

dans le sous-arbre de e ls. Cet algorithme eetuant la répliation en parallèle dans les

diérentesbranhesdel'arbre(3,4),possède unelatenelogarithmiqueen latailledel'arbre.

5 Requêtes de déouverte

Unlientenvoiesarequêteàunn÷udquelonquedansl'arbre. Commel'illustrelagure2(a),

larequêteestensuiteroutéedansl'arbrede façonsimpleen remontant tant quel'iddun÷ud

dontl'idestlalefreherhéeauquelasen÷udrenvoielesvaleursdesserviesqu'ilstokeou

qu'elleretombesurunn÷uddontl'idnepréxepluslalef,auquelasonrépondnégativement

au lient.

Le traitement d'une requête sur une haîne partielle se fait en deux phases illustrées sur

lagure2(b). ConsidéronslarequêteDTR*. Onrouted'abordnormalement selonDTRjusqu'à

trouver le n÷ud ave l'id la plus petite préxé par DTR, éventuellement DTR seul. Les lefs

reherhées se trouvent dans le sous-arbre de e n÷ud. Il nous reste à inonder lesous-arbre

ave une latene logarithmique en la taille de l'arbre, grâe au parallélisme. Chaque n÷ud

envoiesesréponsesaulient. Le traitementd'unerequêtesurunintervallesera trèssimilaire,

en utilisant le préxe desdeux bornes eten appliquant le proessuspréédent sure préxe

mais sur haque n÷ud, en limitant la diusion aux branhes de son sous-arbre onernées

potentiellement par larequête.

Figure 2: Déouverte (gauhe: requête simple, droite:autoomplétion). Le lient envoie sa

requête à un n÷ud logique quelonque (1). La requête est routée (2,3,4). Les valeurs sont

retournéesau lient(5).

Notrearhiteturen'estpasnaturellementmultiritère. Nousréonsunarbreparritère,

où haque ouple (

clef

^,

valeur

^{) est enregistré dans l'arbre} orrespondant à l'attribut dérit par

clef

^{. Mettre tous les attributs dans le même arbre} entraînerait des omportements in- désirablessiunservies'appelleommeunsystèmeparexemple. Demême,pouruneinterro-

gation sur

d

^{ritères, lelient lanepour haun desattributsqui} l'intéresseunerequêtedans l'arbre orrespondant. Chaque arbretraitelarequête enparallèle résultant enoreen une la-

tenelogarithmiqueenlatailleagrégéedesarbres. Par exemple,larequête{DTRSM, Linux*,

PowerPC*, *}donneralieuàtroisrequêtestraitéesenparallèle dansl'arbredesnoms,l'arbre

dessystèmesetl'arbredesproesseurs. Surréeptiondesréponses,lelient faitl'intersetion

des valeursreçues pour negarder queles serviesqui respetent lestroislefs spéiées.

6 Analyse

Nous analysons iirapidement lesomplexitésde laTPLD pour les diérentes métriquesdes

réseaux pair-à-pair et ses avantages/inonvénients par rapport aux autres approhes basées

sur desarbres depréxes.

Considéronsun arbrede pluslongpréxe de taille

n

^{. Appelons}

A

^{l'alphabetqui servirait}

à générer les lefs qui seront stokées dans l'arbre. En onsidérant la taille des lefs bornée

par

T max

^{,equisembleréaliste,'estpourquoinousnenouslaneronspasiidansdesaluls}

poussésdeomplexité, lenombredesauts aupire estbornée par

2 × T max

^{. Pour les requêtes}

néessitant l'autoomplétion, le nombre de messages néessaires pour arriver à la raine du

sous-arbreonernéparlarequêteestdelamêmefaçonbornéepar

T max

^{. Ensuite,onnepeut}

de messages linéaire en la taille du sous-arbre. En revanhe, grâe au parallélisme entre les

branhes,lalatenedee parours estenorebornéeparlaprofondeur del'arbreetdonpar

T max

^{. Demême,si l'ononsidère}

A

^{ni,haque n÷udayant par onstrution une entréepar}

aratèredanslatablederoutage,(

k

^enomptantlarépliation,latailledelatablederoutage est toujours bornée par

|A|

^{. Dans lapratique, ela signie quela table de routage peut-être}

allouée statiquement, par exemple sous laforme d'un tableau de

|A|

^{ases. En onséquene,}

la déision loal de routage surhaque n÷ud peut sefaire en temps onstant, en examinant

laase orrespondant auprohainaratère de lalefreherhée.

Critère Skip Graphs Prex HashTree P-Grid TPLD

Nbdemessagespourunereherhesimple

O(log(n)) O(log(D) log(N )) O(log(Π)) O(T max )

Nbdemessagespourunintervalle

O(m log(n)) O(o) O(Π R ) O(l)

Latenepourunintervalle

O(log(n)) O(D) O(log(Π)) O(T max )

Toléraneauxpannes réparation baséesuruneDHT répliation répliation

Loalité - - - gloutonne

Le tableau i-dessus résume les omplexités et fontionnalités de la TPLD etdes autres

approhesbaséessurdesarbreslexiographiques. Bienquel'onpuissemontrerdiérentespro-

priétésintéressantesdeSkipgraphonernantlatoléraneauxpannes,lenombredemessages

néessaires au traitement d'une requêtesurun intervalle esten

O(m log(n))

^où

n

^{est lataille}

totaledel'arbreet

m

^{lenombreden÷udsonernépar}l'intervalle. PrexHashTreeonstruit un arbrelexiographiquedel'ensembledeslefspotentielsdonthaquefeuillegèrel'ensemble

des lefs de la branhe et est aeté à un n÷ud de la DHT sous-jaente. Par l'utilisation

systématique delaDHT,laomplexité d'unerequêtesimpleestainsien

O(log(D) × log(N ))

^,

haque sautdansl'arbre de profondeurbornéepar lataille maximumdeslefs

D

^néessitant

une reherhe dans la DHT de taille

N

^{, on note}

o

^{la taille de la sortie engendrée par une}

requête sur un intervalle. P-Gridonstruit unarbre de préxe statiquement surl'espae des

lefstoutentier,enassoianthaquepairaveunepartiedel'espae,dontlatailleestnotée

Π

^.

Π R

^{notelatailled'unintervalle}

R

^{. Nodewizadopteuneapprohesimilaire}multi-ritèresmais ne seplae pasdansun environnement dynamique, onsidérant lesn÷uds stables,hypothèse

qui semble peu réaliste. Notre arhiteture onstruit un arbre lexiographique réduit, ou de

plus long préxe qui reète mieux l'ensemble des servies eetivement délarées et évitent

des sauts inutiles,

l

^{dénotele nombre de n÷uds du sous-arbre touhé par une requêtesur un}

intervalle. Enn, seulement notre arhiteture s'adapteau réseau sous-jaent, en utilisant la

topologie del'arbre.

7 Simulation

Un simulateur aétédéveloppéen Java,implémentant laréationetl'interrogation del'arbre.

Nous avons utilisé des jeux de données réels ontenant 735 noms de servies, 129 noms de

proesseurs, 189 noms de systèmes d'exploitation ainsi que près de 4000 noms de mahines.

Nous avons d'abord testé le nombre de sauts logiques moyen néessaire à l'insertion d'un

nouveau servie,en prenant leslefs àinsérer aléatoirement danshaun desjeuxd'attributs

ainsiquedans unensemble de 10000mots de taille maximum20 générés aléatoirement dans

unalphabetde65aratères. Laourbe(a)delagure3donnelerésultatdeettesimulation

pourhaundesjeuxdedonnées. Leomportementestlairement logarithmique. Nousavons

0 2 4 6 8 10 12

10 100 1000 10000

Nb de sauts pour une requête d’insertion

Nb de requêtes d’insertion 735 services (1006 noeuds) [moyenne]

189 systèmes (255 nopeuds) [moyenne]

mots aléatoires de 1 à 20 caractères [moyenne]

129 architectures matérielles (173 noeuds) [moyenne]

3985 machines (~5250 noeuds) [moyenne]

a

0 2 4 6 8 10

100 1000

Nombre de sauts pour traiter une requeteª

Taille de l’arbre 3985 machines (5243 noeuds) [moyenne]

b

0 200 400 600 800 1000 1200

0 100 200 300 400 500 600 700

Taille de l’arbre

Nombre de clefs reelles 735 services (1006 noeuds) [moyenne]

0 50 100 150 200

0 20 40 60 80 100 120

Taille de l’arbre

Nombre de clefs reelles 129 processeurs (173 noeuds) [moyenne]

d

Figure3: (a) et(b) : nombre moyen de sauts néessaire au routage. () et(d) : proportion-

nalitéentre nombre de lefs réelsettaillede l'arbre.

dansun arbre de taille bornépar lenombre total de n÷uds (lefs réels et virtuels) résultant

de l'insertion de tous les attributs du jeu de données. Le résultat de l'expériene nous est

donné par la ourbe (b) de lagure 3 qui exhibe de même un omportement logarithmique,

iisur lejeu d'attributsdes mahines (mais leomportement est similairepour tousles jeux

dedonnées.)

Enn, lesourbes()et(d)de lagure3montrent omment évolue lataille del'arbre en

fontion du nombre de lefs réelles délarées. Les deux ourbes sont lairement proportion-

nelles. L'ensemble desexpérienesmontrequelapartdelefs virtuellesesten moyenne de30

%(ave unéart typede 2,4%).

8 Conlusion

Nous avons dérit une nouvelle arhiteture pour une déouverte exible des servies per-

mettant l'autoomplétion des haînes de reherhe partielles. Notre outil est tolérant aux

pannesets'adaptedemanièregloutonneàlatopologieduréseausous-jaent. Lesomplexités

ainsique nosexpérienesde simulationmontrent desaratéristiquesetdesrésultatsintéres-

sants. Nousdévelopponsatuellement unautreméanismedetoléraneauxpannesfondésur

tion présenté ii est préventif. Nousétudions atuellement le développement d'un prototype

de la TPLD permettant d'observer son omportement sur une plate-forme large éhelle an

d'ajuster ertains paramètres ommelefateur derépliation.

Referenes

[1℄ A. Andrzejak and Z. Xu. Salable, eient range queries for grid information servies.

InPeer-to-Peer Computing,pages 3340, 2002.

[2℄ J.Aspnes and G.Shah. Skip Graphs. In Fourteenth Annual ACM-SIAM Symposium on

Disrete Algorithms,pages 384393, January2003.

[3℄ M. Balazinska, H. Balakrishnan, and D. Karger. INS/Twine: A Salable Peer-to-Peer

Arhiteture for Intentional ResoureDisovery. InPervasive, 2002.

[4℄ S. Basu,S. Banerjee, P. Sharma, and S. Lee. NodeWiz: Peer-to-Peer Resoure Disov-

ery for Grids. In 5th International Workshop on Global and Peer-to-Peer Computing

(GP2PC), 2005.

[5℄ A. Datta, M. Hauswirth, R. John, R.Shmidt, and K. Aberer. Range Queries in Trie-

struturedOverlays. In TheFifth IEEE InternationalConferene on Peer-to-Peer Com-

puting, 2005.

[6℄ I.FosterandA.Iamnithi. Ondeath,taxes,andtheonvergeneofpeer-to-peerandgrid

omputing. InIPTPS,pages118128, 2003.

[7℄ L.Gares-Erie, E.W.Biersak, K.W.Ross,P.A.Felber,andG. Urvoy-Keller. Hierar-

hial Peer-to-Peer Systems. Parallel Proessing Letters Volume 13,2003.

[8℄ B.Godfrey,K.Lakshminarayanan,S.Surana, R.Karp, and I.Stoia. Loadbalaningin

dynami struturedP2P systems. InPro. IEEE INFOCOM,Hong Kong, 2004.

[9℄ M.Harren,J.Hellerstein,R.Huebsh,B.Loo,S.Shenker,andI.Stoia.ComplexQueries

inDHT-Based Peer-To-Peer Networks,2002.

[10℄ DavidR.Kargerand MatthiasRuhl. Simpleeientloadbalaningalgorithmsforpeer-

to-peer systems. In IPTPS,pages131140, 2004.

[11℄ D. Oppenheimer, J. Albreht, D. Patterson, and A. Vahdat. Distributed ResoureDis-

overy on PlanetLab with SWORD. In Proeedings of the ACM/USENIX Workshop on

Real, Large Distributed Systems(WORLDS), Deember 2004.

[12℄ S. Ramabhadran, S.Ratnasamy,J. M. Hellerstein, and S. Shenker. Prex hash tree an

indexing data struture over distributed hash tables. In Proeedings of the 23rd ACM

Symposium on Priniples of Distributed Computing,St.John's, Newfoundland, Canada,

july 2004.

[13℄ S. Ratnasamy, P. Franis, M. Handley, R. Karp, and S. Shenker. A Salable Content-

[14℄ C. Shmidt and M. Parashar. Enabling exible queries withguarantees in p2p systems.

IEEE Internet Computing,8(3):1926, 2004.

[15℄ I. Stoia, R.Morris, D. Karger, M. Kaashoek, and H.Balakrishnan. Chord: A Salable

Peer-to-Peer Lookup serviefor Internet Appliations. In ACM SIGCOMM,pages149

160,2001.

[16℄ P. Triantallou and T. Pitoura. Towards a Unifying Framework for Complex Query

ProessingoverStrutured Peer-to-Peer Data Networks. In DBISP2P,2003.

[17℄ Z. Xu, M. Mahalingam, and M. Karlsson. Turning Heterogeneity into an Advantage in

Overlay Routing. In INFOCOM,2003.

[18℄ Z.Xu,R.Min,andY.Hu.HIERAS:ADHTBasedHierarhialP2PRoutingAlgorithm.

InICPP, pages 187,2003.

[19℄ Z.XuandZ.Zhang.BuildingLow-MaintenaneExpresswaysforP2PSystems.Tehnial

report, Hewlett-Pakard Labs, April2002.

[20℄ B.Y.Zhao,Y.Duan,L.Huang,A.D.Joseph,andJ.D.Kubiatowiz.Broade: Landmark

Routing onOverlay Networks. InIPTPS,2002.