Mod`ele `a ´etats et protocoles de service instantan´ement stabilisants

Gestion des requˆetes. Nous avons vu qu’un protocole de service initie, via une action de d´emar-rage, un service suite `a la demande d’un processeur initiateur. Cette demande est effectu´ee via une

requˆete ext´erieure au protocole. Pour les protocoles de service non-tol´erants aux fautes ainsi que la

plupart des protocoles de service instantan´ement stabilisants, cette notion de requˆete, bien qu’es-sentielle, est implicite (i.e., elle n’apparaˆıt pas clairement dans le code des protocoles). Cependant, chaque action de d´emarrage est suppos´ee ˆetre ex´ecut´ee uniquement `a la suite d’une requˆete. En ce qui concerne les protocoles de service auto-stabilisants nous avons vu que la notion de requˆete avait pu-rement et simplement disparu car ces protocoles r´ep`etent les cycles de calcul `a l’infini afin d’assurer la convergence du syst`eme (cf. section 3.2.2).

Dans cette th`ese, nous avons choisi d’expliciter les requˆetes dans le code de nos protocoles. Expli-citer la requˆete permet de montrer que dans la plupart des cas, comme dans [CDPV04, CDV05b], les protocoles de service instantan´ement stabilisants finissent par atteindre une configuration terminale en cas d’absence totale de requˆetes.

Puisque nos protocoles sont ´ecrits dans le mod`ele `a ´etats, nous g´erons les requˆetes via une variable partag´ee Request_i ∈ {W ait,In,Out}1et d´efinie comme entr´ee-sortie dans l’algorithme de chaque initiateur i. Ensuite, nous consid´erons que Requesti = W ait signifie que l’initiateur i demande et

“attend” le service. Lors de l’initiation du service demand´e (i.e., lorsque i ex´ecute une action de d´emarrage relative au service demand´e), Request_ipasse de W ait `a In pour signifier que la requˆete a ´et´e prise en compte par le syst`eme. Finalement, Requestipasse de In `a Out lorsque i d´ecidera que le service demand´e a ´et´e effectu´e. Donc, le syst`eme sera prˆet `a ex´ecuter une nouvelle requˆete `a partir du processeur i uniquement lorsque la variable Request_i sera (`a nouveau) ´egale `a Out. Naturellement, les transitions de W ait `a In et de In `a Out sont g´er´ees dans le code du protocole mˆeme, tandis que la transition de Out `a W ait est g´er´ee de mani`ere externe (i.e., cela signifie qu’un autre protocole, appel´e application, doit effectuer cette transition). Il est important de noter que seules les transitions cit´ees pr´ec´edemment sont autoris´ees : toutes les autres transitions, par exemple la transition de In vers W ait, sont interdites. Dans la suite, nous repr´esenterons l’action correspondant `a la requˆete externe par la r`egle IR2(cette r`egle est d´efinie pour chaque initiateur i) :

IR :: ApplicationRequest(i) ∧ (Requesti = Out) → Requesti:= W ait; ApplicationReleasei;

Dans cette r`egle, ApplicationRequest(i) est un pr´edicat qui est vrai lorsqu’une application de l’ini-tiateur i demande un service. ApplicationRelease<sub>i</sub> est une fonction qui contient le code que l’ap-plication doit ex´ecuter lorsque la requˆete est prise en compte par le syst`eme. En particulier,

Appli-cationRequest(i) doit devenir faux suite `a l’ex´ecution de ApplicationReleasei. Par la suite, nous

1Pour ´eviter toute ambigu¨ıt´e, cette variable pourra ˆetre not´eeP.Requestipour faire r´ef´erence `a la variable Request_i sp´ecifique au protocoleP.

4.3 Mod`ele `a ´etats 37 supposerons que, d`es qu’il est satisfait, le pr´edicat ApplicationRequest(i) reste vrai continˆument jusqu’`a ce que la r`egle IR soit ex´ecut´ee.

Configurations initiales normales d’un protocole mono-initiateur. La notion de l´egitimit´e n’est pas discriminatoire en stabilisation instantan´ee : comme le syst`eme v´erifie toujours ses sp´ecifica-tions, toute configuration est consid´er´ee comme l´egitime. Cependant, pour les protocoles de service instantan´ement stabilisants, nous distinguerons souvent un sous-ensemble de configurations dit

en-semble des configurations initiales normales (cette distinction est aussi valable pour les protocoles

de service auto-stabilisant). En fait, les configurations initiales normales correspondent aux configu-rations de d´emarrage du syst`eme une fois que les comportements “anormaux” dˆus aux fautes tran-sitoires ont ´et´e supprim´ees. Cette notion permet notamment d’´etudier le surcoˆut de la stabilisation. Nous d´efinissons maintenant la notion de configuration initiale normale d’un protocole de service mono-initiateur. Cette notion fait appel deux autres concepts d´efinis ci-dessous : les configurations

originelles et les configurations normales.

Les configurations originelles d’un syst`eme correspondent `a l’initialisation des variables du pro-tocole dans un environnement sans panne avant la premi`ere ex´ecution. Dans ce cas, tous les proces-seurs sont en attente du d´emarrage de l’ex´ecution, d´emarrage qui sera assur´e par l’initiateur lorsque celui-ci recevra une requˆete.

L’ensemble des configurations normales repr´esente l’ensemble des configurations possibles dans une ex´ecution n’ayant jamais subi de fautes.

L’ensemble des configurations initiales normales ne se limite a priori pas aux configurations de l’ensemble des configurations originelles. En effet, en r´egime normal, un protocole mono-initiateur peut d´emarrer un nouveau cycle de calcul `a partir d’une configuration dans laquelle des reliquats du cycle de calcul pr´ec´edent perdurent dans le r´eseau. Or, comme ces reliquats ne sont pas cons´ecutifs `a un comportement anormal du syst`eme, cette configuration initiale doit ˆetre consid´er´ee comme nor-male (nous verrons un exemple de ce type de configuration dans la sous-section 5.4.1).

D´efinition 4.3.2 (Configuration originelle) Nous appelons ensemble des configurations originelles d’un protocole de service mono-initiateurP le sous-ensemble de configurations γiv´erifiant :

1. ∀p ∈ V , p n’est pas activable dans γi.

2. L’initiateur p v´erifie Request_p = Out (i.e., p est prˆet `a recevoir une requˆete) dans γi.

3. L’initiateur p est activable dans γi+1 ^{si et seulement si p rec¸oit une requˆete dans γ}i → γi+1

(i.e., la r`egle IR de p est ex´ecut´ee dans γ_i → γi+1^).

D´efinition 4.3.3 (Configuration normale) Une configuration normale du protocole de service mo-no-initiateurP est une configuration accessible `a partir d’une configuration originelle (les

configu-rations originelles incluses).

D´efinition 4.3.4 (Configuration initiale normale) Une configuration initiale normale du protocole de service mono-initiateurP est une configuration normale de P, γi, o`u l’initiateur p v´erifie :

– p n’est pas activable dans γ_i, et

Deuxi`eme partie

Contributions

Chapitre 5

Parcours en profondeur instantan´ement

stabilisants

Le parcours en profondeur (DF S : Depth-First Search) est le parcours s´equentiel le plus clas-sique de la litt´erature [Tar72]. Le parcours en profondeur a de nombreuses applications. Dans les syst`emes distribu´es, il est principalement utilis´e pour r´esoudre le probl`eme d’exclusion mutuelle. Cependant, il peut ˆetre utilis´e pour r´esoudre de nombreuses autres tˆaches : par exemple, le calcul d’arbre couvrant ([HC93]), la programmation par contrainte ([JSYZ04]), le routage par intervalle ([vLT87]) ou pour ´evaluer des propri´et´es globales sur le r´eseau telles que les points d’articulation (cf. [Tar72] et section 5.7).

Dans ce chapitre, nous allons tout d’abord d´efinir formellement le concept de parcours en deur (section 5.1). Nous proposons ensuite un ´etat de l’art non exhaustif sur les parcours en deur distribu´es (section 5.2). Puis, nous pr´esentons deux protocoles basiques de parcours en profon-deur non-tol´erants aux fautes, l’un dans le mod`ele `a passage de messages et l’autre dans le mod`ele `a ´etats. Nos solutions instantan´ement stabilisantes sont pr´esent´ees dans les sections 5.4 et 5.5. Nos deux parcours en profondeur sont des protocoles instantan´ement stabilisants ´ecrits dans le mod`ele `a ´etats (cf. section 4.3). Le premier (section 5.4) est bas´e sur des listes d’identit´es. Le second (section 5.5) utilise un principe de question/r´eponse pour remplacer les listes d’identit´es. Il faut noter que ces deux solutions fonctionnent sous l’hypoth`ese d’un d´emon distribu´e in´equitable : le d´emon le plus g´en´eral du mod`ele `a ´etats. Comme expliqu´e dans la sous-section 4.3.3, le code de ces deux protocoles fera ex-plicitement r´ef´erence aux requˆetes via la variable partag´ee Request. Cependant, pour simplifier l’ana-lyse des protocoles, nous ne tiendrons pas compte, dans un premier temps, de cette variable Request dans les preuves. Nous traiterons la gestion explicite de la requˆete dans une section ind´ependante (cf. section 5.6) et notamment des r´epercussions au niveau de la complexit´e en temps. Enfin, nous pr´esenterons dans la section 5.7 deux applications instantan´ement stabilisantes pouvant ˆetre obte-nues `a partir de nos deux protocoles de parcours en profondeur. Ces deux applications ´evaluent des propri´et´es globales sur le r´eseau. La premi`ere application (cf. sous-section 5.7.3) est un calcul de point fixe avec d´etection de terminaison. L’algorithme pr´esent´e permet de marquer les points

d’ar-ticulation (d´efinition A.2.15, page 161) et les isthmes (d´efinition A.2.16, page 161) du r´eseau. Les

points d’articulation (resp. les isthmes) sont des processeurs (resp. des canaux) dont la suppression (suite `a une panne d´efinitive, par exemple) provoque la partition du r´eseau en plusieurs composantes connexes. De plus, l’existence de points d’articulation ou d’isthmes dans le r´eseau peut ˆetre l’une des causes d’apparition de congestions. L’identification des points d’articulation et des isthmes est donc essentielle du point de vue de la tol´erance aux fautes. La seconde application (cf. sous-section 5.7.4) permet d’´evaluer si un ensemble fourni par l’application est un ensemble s ´eparateur (d´efinition A.2.14, page 161) du r´eseau. Un ensemble s´eparateur (cutset) est un sous-ensemble de processeurs du r´eseau dont la suppression (suite `a des pannes d´efinitives, par exemple) provoque la partition du

42 Parcours en profondeur instantan´ement stabilisants r´eseau en plusieurs composantes connexes. La d´etection d’ensembles s´eparateurs est un probl`eme important dans de nombreuses applications telles que l’´evaluation de la fiabilit´e des r´eseaux.

5.1 D´efinition

Le concept de parcours en profondeur est bas´e sur la notion de parcours s´equentiel. Donc, avant de d´efinir le parcours en profondeur (sous-section 5.1.2), nous allons d´efinir la notion de parcours s´equentiel (sous-section 5.1.1).