Scribe

Scribe [6] est une infrastructure construite au-dessus de la couche de routage Pastry qui permet d’effectuer du multicast applicatif `a grande ´echelle. Ainsi, chaque noeud appar-tenant au syst`eme Scribe⁸ peut joindre un groupe, cr´eer un groupe, envoyer des messages en mode multicast `a l’ensemble des membres d’un groupe. Il est `a noter qu’un noeud peut appartenir `a plusieurs groupes, l’ensemble des groupes ´etant extensible et pouvant ˆetre de taille importante. Chacun de ceux-ci peut ˆetre constitu´e d’un grand ensemble de membres pouvant ˆetre compos´e de plusieurs sources ainsi que de plusieurs membres r´ecepteurs.

Scribe construit un arbre multicast (par groupe) recouvrant l’ensemble de ces membres,

7cet aspect sera trait´e dans un chapitre suivant.

8Ensemble de noeuds Pastry ex´ecutant Scribe.

l’un d’eux ´etant la racine de ce dernier et est appel´e le point de rendez-vous.

Scribe offre une API simple aux applications de communication de groupe :

create(credentials, groupId) permet de cr´eer un groupe ayant pour identifiant grou-pId; credentials ´etant utilis´e pour les droits d’acc`es.

join(credentials, groupId, messageHandler) permet au noeud local de joindre le groupe groupId. L’ensemble des messages multicast re¸cus pour ce groupe ´etant transf´er´e `a la routine de traitement des messagesmessageHandler.

leave(credentials, groupId) permet au noeud local de quitter le groupe.

multicast(credentials, groupId, message) permet d’envoyer un message au groupe sp´ecifi´e en mode multicast.

Chaque groupe est identifi´e par un identifiant qui est, tout comme pour les noeuds de Pastry, calcul´e par l’interm´ediaire d’une fonction de hashage r´esistant aux collisions sur base du nom (au format textuel) du groupe. Le noeud Scribe ayant son identifiant le plus proche num´eriquement de l’identifiant d’un groupe se verra d´esign´e comme ´etant le point de rendez-vous de celui-ci et deviendra, par cons´equent, la racine de l’arbre multicast de ce dernier. Un tel arbre est compos´e de noeuds appel´esforwarders qui peuvent ˆetre ou non membres du groupe consid´er´e. Ces noeuds ont pour but de maintenir la structure d’arbre en utilisant une table de noeuds enfants appartenant `a l’arbre multicast.

Joindre le r´eseau

Ainsi, lorsqu’un noeud Scribe souhaite joindre un certain groupe, il va, via la couche de routage Pastry, router un message JOIN qui aura comme cl´e l’identifiant du groupe. Ce message va donc traverser un ensemble de noeuds jusqu’`a arriver au noeud num´eriquement le plus proche de la cl´e, `a savoir le point de rendez-vous du groupe. Chacun de ces noeuds interm´ediaires va v´erifier dans sa liste de groupe s’il constitue d´ej`a un forwarder pour ce dernier. Si c’est le cas, il va ajouter le noeud `a sa liste d’enfants pour ce groupe et arrˆeter de router le message. Dans le cas contraire, il va ajouter ce groupe dans sa liste et ajouter

il va router `a son tour un message JOIN jusqu’au point de rendez-vous. Ce m´ecanisme est illustr´e `a la figure 4.2.

1001 1111

1100 Racine

1101

0100

0111

Fig. 4.2 – Inscription `a un groupe de discussion via l’envoi d’un message JOIN

Sur la figure 4.2, l’identifiant de certains noeuds a ´et´e indiqu´e. Ici est faite l’hypoth`ese d’un groupe ayant comme identifiant 1100 et ayant comme point de rendez-vous le noeud ayant le mˆeme identifiant. Le noeud 0111, souhaitant joindre le groupe, va envoyer un message JOIN vers le noeud 1001. Ce dernier va `a son tour router le message au noeud 1101 qui va finalement envoyer ce message au point de rendez-vous 1100. Cette route est indiqu´ee sur la figure `a l’aide des fl`eches de couleur rouge.

Imaginons maintenant que les noeuds 1001 et 1101 ne font pas encore partie des for-warders pour ce groupe. Le message JOIN envoy´e par le noeud 0111 aura, dans ce cas, pour effets d’incomber `a ces derniers la tˆache deforwarder et d’ajouter le noeud 0111 `a la table d’enfants du noeud 1001 et 1001 `a la table d’enfants de 1101.

Par la suite, si le noeud 0100 d´ecide ´egalement de joindre le groupe, ce dernier va en-voyer un message JOIN qui devrait, en temps normal⁹, suivre le chemin vert. Toutefois,

9Sans la pr´esence desforwarders 1001 et 1101.

´

etant donn´e que le noeud 1001 estforwarder de ce groupe, celui-ci va ajouter le noeud 0100

`

a sa table d’enfants pour ce groupe et ne va pas router le message JOIN.

Quitter le r´eseau

Dans le cas o`u un noeud Scribe souhaite quitter un groupe, il enl`eve ce dernier de son ensemble de groupe. Ensuite, il va v´erifier si sa table d’enfants est vide. Si tel est le cas, il va envoyer un message LEAVE au noeud parent dans l’arbre multicast. Ce message va remonter l’arbre r´ecursivement jusqu’`a arriver `a un noeud ayant sa table d’enfants non vide (apr`es avoir retir´e le noeud sortant).

Envoi multicast

Toute source multicast doit connaˆıtre le point de rendez-vous du groupe pour lequel elle veut effectuer l’envoi. Pour ce faire, une source utilise Pastry afin router un message permettant de localiser la racine de l’arbre qui y r´epondra avec son adresse IP. Cette derni`ere sera mise en cache de fa¸con `a ´eviter d’effectuer cette manoeuvre `a chaque envoi multicast. Dans le cas o`u le point de rendez-vous a chang´e ou est d´efaillant, une source utilise `a nouveau Pastry pour trouver la nouvelle racine de l’arbre multicast.

Un message multicast est transmis `a tous les int´eress´es par l’interm´ediaire du point de rendez-vous en parcourant l’arbre multicast `a partir de la racine de la mani`ere suivante : un noeud recevant un message multicast va l’envoyer `a l’ensemble des noeuds faisant partie de la table d’enfants de ce groupe. De plus, si ce noeud est membre du groupe, il transf`ere ce message `a la routine de gestion de messages de l’application.

R´eparation de l’arbre

P´eriodiquement, chaque noeud (n’´etant pas une feuille de l’arbre) appartenant `a l’arbre va envoyer un message HEARTBEAT aux noeuds faisant partie de sa table d’enfants.

Chacun de ceux-ci sait que, s’il ne re¸coit pas ce message, il peut suspecter son parent d’ˆetre d´efaillant. Dans le cas d’une d´efaillance du parent, le noeud va utiliser Pastry afin de router un message JOIN pour le groupe consid´er´e. Pastry va donc permettre de reconstruire l’arbre en suivant le m´ecanisme utilis´e pour joindre un groupe. Il est `a noter que l’envoi d’un message multicast aux enfants d’un noeud peut ˆetre consid´er´e comme ´etant ´egalement

Scribe prend ´egalement en compte la d´efaillance possible du point de rendez-vous d’un groupe. Pour ce faire, l’´etat¹⁰ de ce point est r´epliqu´e aux k noeuds les plus proches ap-partenant donc au leaf set de la racine de l’arbre. Ainsi, lors de la d´efaillance du point de rendez-vous, un de ces noeuds r´eplicas va la d´etecter et va router par l’interm´ediaire de Pastry un message JOIN, qui arrivera au nouveau point de rendez-vous.

En ce qui concerne les enfants d’un noeud, ceux-ci doivent envoyer p´eriodiquement un message `a leur parent, indiquant ainsi qu’ils souhaitent continuer de faire partie du groupe.

Dans le cas contraire, le parent enl`evera l’enfant de sa table.

10Celui-ci est compos´e de l’identit´e du cr´eateur du groupe ainsi de la liste de contrˆole d’acc`es.

Architecture P2P sur une couche de transport service web

5.1 Pr´ esentation g´ en´ erale

Ce chapitre a pour but d’effectuer une corr´elation entre les diff´erents concepts abord´es dans les trois chapitres pr´ec´edents (2`a4) en pr´esentant les diff´erents d´etails d’une applica-tion. Cette derni`ere, but principal de ce m´emoire, consiste en un middleware utilisant les diff´erents standards des services web qui a pour buts la cr´eation de chemins de routage au sein d’un r´eseau peer-to-peer ainsi que de permettre une communication de groupe au sein de ce dernier. Par communication de groupe, il est ici entendu de permettre la cr´eation de groupes de r´eception dans lesquels auront lieu des envois de messages en mode multicast ainsi qu’en mode anycast.

C’est donc tout logiquement que le design de cette application se d´ecompose en trois couches illustr´ees `a la figure 5.1 et d´ecrites ci-dessous :

La couche de transport : cette couche a pour but de v´ehiculer les diff´erents messages provenant des couches sup´erieures. Ce rˆole sera rempli par les services web.

La couche de routage P2P : cette couche est destin´ee `a la maintenance du r´eseau peer-to-peer ainsi qu’`a la formation des chemins de routage au sein de celui-ci. Cette couche se devra d’ˆetre performante afin d’accepter un grand nombre d’utilisateurs. De plus,

Couche de transport : Services Web Couche de routage P2P

Couche de communication de groupe

Fig. 5.1 – D´ecoupage en couches de la solution

prunte un chemin optimis´e en terme de distance.

La couche de communication de groupe : elle aura pour tˆaches la formation de groupes ainsi que la maintenance des structures associ´ees, le support de messages en modes multicast et anycast envoy´e `a ces groupes.

Ce chapitre va, dans un premier temps, pr´esenter les avantages ainsi que les inconv´enients d’une combinaison de la technologie des services web avec les r´eseaux peer-to-peer. Par la suite, apr`es avoir justifi´e les diff´erents choix op´er´es au niveau des diff´erents protocoles, ce chapitre s’attardera sur les aspects techniques des diff´erentes couches de l’application.

Finalement, l’application bas´ee sur ces diff´erentes couches sera d´etaill´ee et un exemple d’ex´ecution sera pr´esent´e et comment´e.