Mesures de performances dune primitive de diffusion atomique dans un cluster

Par exemple : Si un processus correct envoie un message à un processuscorrect de destination, le processus de destination devrait éventuellementrecevoir ce message.. Par exemple le proce

Rapport du stage eectué du 1 mai 2007 au 31

octobre 2007 Dans la société:

Laboratoire d'Informatique de Paris 6

Pierre Sutra, doctorant INRIA-LIP6

4 février 2008

Avant tout développement sur cette expérience professionnelle, il raît opportun de commencer ce rapport de stage par des remerciements, àceux qui m'ont beaucoup appris au cours de ce stage, et même à ceux quiont eu la gentillesse de faire de ce stage un moment très protable

appa-Aussi, je remercie le Professeur Marc Shapiro et Pierre Sutra, mes maîtres

de stage qui mónt formé et accompagné tout au long de cette expérience fessionnelle avec beaucoup de patience et de pédagogie Enn, je remerciel'ensemble des stagiaires du bureau 849 pour les aides qu'ils ont pu me pro-diguer au cours de ces six mois

Pour accéder aux données partagées dans un système réparti, en misant les passages par le réseau, il faut les répliquer Il existe de nombreuxalgorithmes pour assurer la cohérence des réplicats en présence de mises àjour, mais ces derniers n'ont pour l'instant jamais fait l'objet d'une compa-raison systématique

mini-L'objectif de ce stage est pour étudier, simuler, et mesurer les algorithmes

de cohérence de la littérature, en particulier ceux conçus pour le consensus

et la diusion atomique Ce travail s'appuiera sur le framework Appia quel'équipe de l'université de Lisboa développe L'émulation est lancé sur lecluster du groupe REGAL

To access the data shared in a distributed system with the minimum ofthe passages in the network, the data should be replicated There are manyalgorithms to ensure the coherence of the data when the replications areupdated But it does not exist a comparison of these algorithms

The objective of this training course is to study, simulate and measurethese algorithms of data's coherence, in particular those are conceived forthe agreement problems which are the consensus and the atomic broadcast.Then we try to implement and stimulate these algorithms on the Appia fra-mework which is developped by the group of the university Lisboa We runthe emulation on the cluster of the REGAL group of LIP6

Table des matières

1.1 Bref descriptif du laboratoire 6

1.2 Problématique et objectifs du rapport 7

1.3 Annonce de plan 7

2 Principes de base 8 2.1 Système réparti 8

2.1.1 Horloge logique 8

2.1.2 Horloge physique 8

2.1.3 Processus et Messages 8

2.1.4 Automate et Etape 9

2.1.5 Sûreté et Vivacité 9

2.2 Processus 10

2.2.1 Processus en pannes 10

2.2.2 Crash 10

2.2.3 Fautif comportement 10

2.2.4 Dépassement de tampon 10

2.2.5 Récupération 11

2.3 Hypothèse de temps 11

2.3.1 Systèmes synchrones et asynchrones 11

2.4 Détecteur de défaillances 12

2.4.1 Variances de détecteurs de défaillances 14

2.5 Détecteur de défaillances parfait P 14

2.5.1 Algorithme pour le détecteur de défaillances 15

3 Problème d'accord 16 3.1 Introduction 16

3.2 Diusion able 17

3.2.1 Spécications 17

3.2.2 Protocole de diusion able 17

3.3 Problème consensus 18

3.3.1 Spécications 18

3.3.2 Variances 18

3.3.3 Consensus en l'absence de pannes 20

3.3.4 Consensus synchrone avec pannes 21

3.3.5 Algorithme de Paxos 22

3.3.6 Consensus avec le détecteur parfait 23

3.4 Diusion atomique 25

3.4.1 Transformation du Consensus à la Diusion Atomique 26 3.4.2 Transformation de la Diusion Atomique au Consensus 26 3.5 Diusion atomique avec les fautes 26

3.5.1 Algorithme 27

4 Travaux eectués 28 4.1 Appia 28

4.1.1 Modèle de la composition 28

4.1.2 Modèle de l'interaction 30

4.1.3 Modèle concourant 30

4.2 Cluster 31

4.3 Déploiement l'Appia sur le cluster 31

4.3.1 Lancement concurrent des processus 32

4.3.2 Préparation avant de l'utilisation ssh 32

4.3.3 Exécution des processuss 33

4.4 Mesure de la performance 33

4.4.1 Nombre de messages et Nombre des rounds 35

4.4.2 Temps d'exécution 36

4.4.3 Nombre maximal des processus 38

4.5 Modication 38

5 Conclusions et perspectives 40 5.1 Conclusions 40

5.2 Perspectives 40

Chapitre 1

Introduction

1.1 Bref descriptif du laboratoire

Le LIP6 est un laboratoire de recherche sous tutelle de l'Université Pierre

& Marie Curie, et du CNRS Avec 128 chercheurs permanents et 231 rants, il est l'un des principaux laboratoires de recherche en informatique enFrance

docto-Le laboratoire couvre un large spectre d'activités regroupées au sein decinq départements : Calcul Scientique ; DEcision, Systèmes Intelligents etRecherche opérationnelle ; Données et Apprentissage Articiel ; Réseaux etSystèmes Répartis ; Systèmes Embarqués sur Puce En complément de la re-cherche académique, le LIP6 a une longue tradition de coopération avec despartenaires industriels dans de très nombreux projets nationaux, européens

ou internationaux Deux centres R&D ont été créés : le CERME, Centre ropéen de Recherche en Micro-Electronique sur les systèmes embarqués, etEuronetlab, sur l'internet et les réseaux de télécommunication Le LIP6 estégalement impliqué dans les pôles de compétitivité de l'Ile-de-France : CapDigital sur le contenu numérique et System@tic sur les systèmes embarqués

Eu-Il a également des équipes communes avec l'INRIA sur les thématiques ducalcul formel et des systèmes répartis La coopération internationale est uneconstante pour les activités du laboratoire Le LIP6 est membre de plusieursréseaux d'excellence et développe également des relations suivies avec desuniversités au Brésil, aux États-Unis, au Japon, et dans de nombreux payseuropéens Le laboratoire est largement ouvert aux projets de coopération

et à l'accueil de visiteurs scientiques Le laboratoire est impliqué dans desenseignements liés à la recherche, qui sont dispensés au Master "Sciences ettechnologie" à l'Université Pierre et Marie Curie L'EDITE de Paris (EcoleDoctorale d'Informatique, Télécommunication et Electronique de Paris) ac-cueille ses doctorants

REGAL (Répartition et Gestion des Applications à Large échelle) estune équipe commune avec l'INRIA Rocquencourt L'objectif de l'équipe est

la gestion de ressources dans le cadre très dynamique de grands réseaux GAL s'intéresse aux techniques de déploiement d'applications (code et don-nées) adaptées aux environnements extrêmement distribués de grande taille(nombre de processeurs, distances), fortement dynamiques, hétérogènes, sanspossibilité simple de gestion centralisée et/ou instantanée de la connaissancemutuelle L'approche de REGAL repose sur des techniques de réplication

RE-et d'adaptation dynamique dans lesquelles un code applicatif RE-et ses nées sont dupliqués sur plusieurs sites ce qui permet de tolérer les fautes,d'augmenter la disponibilité et réduire les temps d'accès du service rendupar l'application Cet équipe étudie la façon dont les systèmes peuvent ga-rantir une qualité de service en termes de abilité, disponibilité et cohérence

don-1.2 Problématique et objectifs du rapport

Il existe de nombreux algorithmes pour assurer la cohérence des réplicatsdes données partagées dans un système réparti Il a besoin d'une solutionpour que tous les instances partagées aient les mêmes décisions ou bien lesmêmes décisions en même ordre

L'objectif de ce stage est d'étudier ces algorithmes du problème cord Ce sont le consensus et la diusion atomique En suite on observe lecode source libre Appia qui a déjà implémenté ces algorithmes en langageJAVA On va déployer l'Appia sur le cluster du LIP6 En n, on mesure laperformance de l'algorithme de la diusion atomique : nombre de messages,nombre des rounds, temps d'exécution

d'ac-1.3 Annonce de plan

Ce rapport se compose 4 sections principales La section 1 introduit del'objetif du stage et un bref descriptif du laboratoire LIP6 La section 2 rap-pelle les notations très connues dans un système reparti La section 3 présenteles problèmes d'accord Dans cette part, on concentre au consensus et à ladiusion atomique Ces problèmes d'accord sont observés sur l'environne-ment d'un système asynchrone avec le détecteur parfait des défaillances Lasection 4 montre mon travaux Je vais déployer l'implémentation des algo-rithmes du consensus et de la diusion atomique sur un cluster En suite

je mesure la performance de ce système : le nombre de messages échangés,

le nombre de rounds, le temps d'exécution Les sections suivantes sont lesconclusions, les perspectives et les bibliographies

Chapitre 2

Principes de base

2.1 Système réparti

2.1.1 Horloge logique

L'horloge logique est dénie comme l'assignation un nombre du temps

ó l'événement s'est produit De manière plus précise, une horloge Ci lié à

un processus Pi est une fonction qui assigne un nombre Ci(a) à n'importequel événement a dans ce processus

Dans cette fonction, l'événement a s'exécuté avant l'événement b si C(a) <C(b) Cette condition est utile pour déterminer l'ordre des messages échan-gés dans le système réparti

2.1.2 Horloge physique

L'utilisation de l'horloge logique est uniquement utile dans le cas ó lesévénements sont dans un même processus En conséquence, dans le cas óles événements sont de diérents processus, l'horloge physique est souventutile

2.1.3 Processus et Messages

Processus

Dans un système réparti, le processus est déni comme les unités quipeuvent exécuter des calculs Un processus peut être un processeur, un pro-cessus d'exécution, un thread ou un système d'exploitation

Le processus a les propriétés suivantes :

-Les processus savent de l'un à l'autre

-Les processus du système se lancent avec le même algorithme.

-Tous les processus se forment l'algorithme distributé

un message à un processus single

Etape

Une exécution d'un automata d'un algorithme est représentée par unordre ni des étapes dans le cas ni et par un ordre inni des étapes dans lecas inni

Une étape de processus consiste à :

- délivrer un message d'un autre processus (événement global)

- exécuter un calcul local (événement local)

- envoyer un message à un certain processus (événement global)

L'exécution du calcul local et de l'envoi d'un message sont déterminés parl'automate de processus, c'est-à-dire, l'algorithme Les événements locauxsont produits par les étapes échangés entre les modules du même processusaux diérentes couches

2.1.5 Sûreté et Vivacité

Pour construire une application ecace et stable, l'algorithme nécessite

2 propriétés suivantes : sûreté et vivacité

La propriété de sûreté déclarent que l'algorithme devrait nous donner

le vrai résulat

Par exemple : Le processus ne devrait que recevoir un message seulements'il a été diusé par un processus.

De toute façon, les propriétés de sûreté ne sont pas assez Parfois, unebonne manière d'empêcher de mauvaises choses de se produire consiste àfaire rien

La propriété vivacité assure que quelques bonnes choses se produisentéventuellement

Par exemple : Si un processus correct envoie un message à un processuscorrect de destination, le processus de destination devrait éventuellementrecevoir ce message La propriété de vivacité est énoncé que pour n'importquel le temps t, il y un espoir que la propriété peut être satisfait à un moment

2.2.2 Crash

Un processus est "crash" s'il ne nit pas ses fonctions Par exemple, aulieu d'échanger les messages, le processus n'envoie plus aucun message àl'autre Les messages sont perdus en l'entrée ou en la sortie ou tous les deux

2.2.3 Fautif comportement

Au contraire le dernier, le fautif comportement est déni que l'un cessus ne fonctionne pas correctement et il donne des résultats aléatoires.Par exemple, un processus envoie les messages à l'extérieur ou bien plusnombreux messages nécessaires

pro-2.2.4 Dépassement de tampon

Dans le cas du dépassement de tampon, le processus ne marche plus Il

ne peut pas envoyer ni recevoir aucun message On voit que le temps deréponse du système dépasse les exigences des spécications

2.3.1 Systèmes synchrones et asynchrones

Dans un système réparti les composants exécutent des opérations à desvitesses diérentes Par exemple le processeur d'un seveur est généralementplus rapide que celui utilisé dans un commutateur ou dans une carte réseau.Les messages sont aussi reçus avec des délais diérents en fonction de laqualité des liens physiques et du nombre de bonds nécessaires pour pave-nir jusqu'au destinaire.Toutefois diérents phénomènes comme la charge, lespriorités assignés aux processus, et le type d'ordonnaceur ont des eets surles vitesses auxquelles s'exécutent les algorithmes

Fort de ce constat, on classie les systèmes répartis en deux types :-Les systèmes synchrones dans lequel la vitesse des processus et descanaux est bornée et connue

-Les systèmes asynchrones dans lequel la vitesse des processus et descanaux est bornée, mais la bornée est inconnue

Fig 2.1  Détecteurs de défaillances

2.4 Détecteur de défaillances

Il existe toujours les erreurs (les processus en pannes) dans la plupart desystèmes T.Chandra et S.Toueg [CT96] ont montré que le problème d'accord(plus détail dans la suite) ne peut pas être résolu dans le cas ó il y a un seulprocessus étant en pannes lorsque les autres processus ne connaissent pas

En conséquence, le détecteur de défaillances est vraiment nécessaire dans lesystème réparti

Qu'est-ce qu'un détecteur de défaillances ?

Un détecteur de défaillances est un service réparti composé de détecteurslocaux attachés à chaque processus Un détecteur fournit sur la demande

la liste des processus qu'il soupçonne d'être en panne Les divers détecteurslocaux coopèrent entre eux pour établir cette liste

Rơle

Constatant que la détection des défaillances dans un système reparti chrone est obligatoire Chaque processus a l'accès à un module de détectionlocale de défaillance qui maintient une liste de processus suspectés d'êtredéfaillants Le module de détection de défaillances est tombé en ajoutant unprocessus non défaillant à sa liste de suspects Si ce module découvre plustard qu'il a fait une erreur, il enlève le processus faute suspecté de la listedes suspects Ainsi, le détecteur de défaillance peut ajouter et enlever lesprocessus de sa liste des suspects plusieurs fois pendant son exécution Enoutre, à un instant donné, deux modules dans deux hơtes diérents peuventavoir des listes de suspects diérentes Chandra et Toueg [CT96] ont montréqu'il est possible de résoudre le problème du consensus dans des systèmesrépartis asynchrones munis de détecteurs de défaillances non ables satisfai-sant certaines propriétés de exactitude (relative à la vivacité), limitant lesfausses suspicions, et de complétude (relative à la sûreté), assurant la détec-

syn-tion eective des processus défaillants.

Formellement, l'historique H d'un détecteur de défaillances est une

fonc-tion de l'ensemble Q x T vers l'ensemble 2π ó H(p, t) est la valeur du

détecteur de défaillances du processus p à l'instant t dans H Si q ∈ H(p, t)

alors p suspecte q à l'instant t dans H Si p 6= q alors H(p, t) 6= H(q, t)

est possible Un détecteur de défaillances D est une fonction qui associe à

chaque modèle de défaillance F un ensemble d'historiques de détecteurs de

défaillances D(F ) D(F ) est l'ensemble de tous les historiques pouvant

exis-ter durant les exécutions avec l'ensemble des défaillances F et le détecteur

de défaillances D Chandra et Toueg dénissent deux propriétés de

complé-tude et quatre de exacticomplé-tude donnant, une fois combinées, huit classes de

détecteurs de défaillances

1.Complétude : Le détecteur doit détecter les processus fautifs

Complétude forte : Tout processus fautif nit par être soupçonné par

tout processus correct

∀F, ∀H ∈ D(F ), ∃t ∈ T, ∀p ∈ crash(F ), ∀q ∈ correct(F ), ∀t0 ≥ t : p ∈ H(q, t0)(2.1)Complétude faible : Tout processus fautif nit par être soupçonné par

un processus correct

∀F, ∀H ∈ D(F ), ∃t ∈ T, ∀p ∈ crash(F ), ∃q ∈ correct(F ), ∀t0 ≥ t : p ∈ H(q, t0)(2.2)2.Exactitude : Le détecteur ne doit pas déclarer faussement un proces-

sus correct

Exactitude forte : Aucun processus correct n'est jamais soupçonné par

un autre processus correct

∀F, ∀H ∈ D(F ), ∀t ∈ T, ∀p, q ∈Y−F (t), p /∈ H(q, t) (2.3)

Exactitude faible : Il existe un processus correct qui n'est jamais

soup-çonné par un autre processus correct

∀F, ∀H ∈ D(F ), ∃p ∈ correct(F ), ∀t ∈ T, ∀q ∈Y−F (t), p /∈ H(q, t)(2.4)

Exactitude éventuellement forte : Au bout d'un certain temps, aucun

processus correct n'est plus jamais soupçonné par un processus correct

∀F, ∀H ∈ D(F ), ∃t ∈ T, ∀t0≥ t, ∀p, q ∈ correct(F ), p /∈ H(q, t0) (2.5)

Exactitude éventuellement faible : Au bout d'un certain temps, il existe

un processus correct qui n'est plus jamais soupçonné par un autre

processus correct

∀F, ∀H ∈ D(F ), ∃t ∈ T, ∃p ∈ correct(F ), ∀t0 ≥ t, ∀q ∈ correct(F ), p /∈ H(q, t0)(2.6)

Une classe des détecteurs de défaillances est déni par un pair de plétude et d'exactitude que les détecteurs de défaillances dans cette classedoivent satisfaire En général, la complétude requiert qu'un détecteur dedéfaillances éventuellement suspecte chaque processus qui se crashe éven-tuellement, pendant que l'exactitude limite les erreurs qu'un détecteur dedéfaillances peut faire Deux propriétés de complétude et quatre propriétésd'exactitude composent huit classes des détecteurs de défaillances suivants :

com-Fig 2.2  8 classes détecteurs de défaillances

Chandra et Toueg [CT96] ont montré que un propriété faible est lente à un propriété correspondant forte

équiva-Par exemple : On sait réaliser la complétude forte si on dispose de la plétude faible

com-2.4.1 Variances de détecteurs de défaillances

A côté de 8 classes ci-dessus, les détecteurs de défaillances sur les systèmesparticuliers ont les propriétés supplémentaires suivantes :

-synchrone : il peut connaître la borne sur le temps de tranmission.-asynchrone : il ne peut pas connaître la borne sur le temps de tranmission.-pannes franches (fail-stop) : soit le processus fonctionne normalement (lesrésultats sont corrects), soit il ne fait rien Il s'agit du type de panne

le plus simple

-pannes byzantines : le détecteur peut capturer non seulement les crashsmais aussi les fautifs comportements

2.5 Détecteur de défaillances parfait P

Dans le cadre de ce stage, on examine le problem d'accord avec le teur de défaillances parfait

détec-L'ensemble de tous tels détecteurs de défaillances est dénoté par les tions de P Similar surgissent pour chaque paire de propriétés de complétude

déni-et d'exactitude Il y a huit telles paires, obtenues en choisissant une des deuxpropriétés de complétude et une des quatre propriétés d'exactitude présen-tées dans la section précédente La notation résultante de dénitions et decorrespondance sont données sur le gure 2.2.

Un détecteur de défaillances serait parfait s'il satisfait la complétude forte etl'exactitude forte

Complétude forte : Tout processus fautif nit par être soupçonné partout processus correct

Exactitude forte : Aucun processus correct n'est jamais soupçonné par

un autre processus correct

2.5.1 Algorithme pour le détecteur de défaillances

Pour implémenter un détecteur de défaillances, une borne de temps mortest utilisé à déteminer un processus qui est en panne ou correct Les processusdoivent envoyer les signaux qui signient vivant Si dans la périod de la borne

de temps mort, un processus qui n'envoie pas le signal vivant est appellé enpanne

Chapitre 3

Problème d'accord

3.1 Introduction

Dans le système réparti, on a plusieurs applications dans lesquelles qu'il

a un ensemble des applications coopératives pour résoudre une même lution Le problème d'accord forme une class fondamental dans le contextedes systèmes répartis Chaque classe a une solution particulier dépend de lal'exigence du problème Il y 3 classes principales du problème d'accord : laréplication, le consensus ainsi que la diusion atomique (la diusion totale-ment ordonnée)

so-La réplication est une technique usuelle permettant d'introduire de laredondance dans un système, an d'en garantir une meilleure disponibilité

Un serveur répliqué est un serveur qui est constitué de plusieurs copies anque, si l'une d'entre elles tombe en panne, les autres puissent continuer àfournir le service Les copies d'un serveur répliqué sont appelées des réplicas.Ces réplicas doivent évoluer de manière cohérente Ainsi, la modication duserveur répliqué nécessite aux réplicas de se mettre d'accord sur l'ensembledes modications à apporter à leurs états respectifs On considère principa-lement deux approches générales permettant de maintenir cette cohérence :

la réplication active et la réplication passive

Le problème du consensus fourni une abstraction à la plupart des autresproblèmes d'accord Tous les processus débutent un consensus en proposantune valeur Puis, tous les processus doivent nalement sélectionner la mêmevaleur v, qui doit être la valeur proposée initialement par l'un des processus

La diusion atomique est un autre problème d'accord Des processusdiusent des messages à tous les processus avec la contrainte que tous lesmessages doivent impérativement être reçus dans le même ordre par tous lesprocessus De surcroît, si un processus reçoit un message m, alors le problème

exige que tous les processus correct aient la garantie de recevoir le message

3.2.1 Spécications

Formellement, la diusion faible est dénie en termes de deux primitifs :diuser(m) et délivrer(m) ó m est un message tiré d'un ensemble de mes-sages possibles Quand un de processus s'exécute diuser(m), nous disonsqu'il a diusé m, et quand un processus s'exécute délivrer(m), nous disonsqu'il recoit le m Nous supposons que chaque message m inclut le champ dé-noté expéditeur(m) qui contient l'identité de l'expéditeur, et un champ avec

un nombre d'ordre ; ces deux champs rendent chaque message unique.Dans la diusion faible, un processus diuse un message à un ensemblespécié de processus (y comprise lui-même) Le protocole doit vérier lestrois propiétés suivantes [Hadzilacos et Toueg 1996]

Accord : Si un processus correct [ou fautif] délivre un message m, tous lesprocessus corrects délivrent m (au bout d'un temps ni)

Validité : Si un processus correct diuse un message m, tous les processuscorrects délivrent le message m (au bout d'un temps ni)

Intégrité : Quel que soit le message m, il est délivré au plus une fois àtout processus correct [ou fautif], et seulement s'il a été diusé par unprocessus

3.2.2 Protocole de diusion able

Tout processus p exécute le programme suivant :

pour exécuter broadcast(m) :

estampiller m avec sender(m) (processus émetteur) et seq(m)

//seq est un numéro de séquence local à l'émetteur

//on a ainsi une identication unique du message

// send(m) et receive(m) sont les primitives du système de// communication able disponible.

send(m) à tous les voisins de p,et à p

//voisin de p :processus q tel qu'il y ait un lien de communication//directe de p vers q

deliver(m) se produit comme suit :

sur exécution de receive(m) par processus p

if p n'a pas précédemment exécuté deliver(m) then

//vérié grâce à l'identication unique de m

if sender(m) 6= p then send(m) à tous les voisins de pdeliver(m)

3.3 Problème consensus

Un consensus est un accord général parmi les membres d'un groupe,pouvant permettre de prendre une décision sans vote préalable Tous lesprocessus débutent un consensus en proposant une valeur Puis, tous lesprocessus doivent nir par prendre la même valeur v, qui doit être la valeurproposée initialement par l'un des processus

3.3.1 Spécications

Dans le problème de consensus, tous les processus corrects proposent unevaleur et doivent prendre une décision unanime et irrévocable sur une cer-taine valeur qui est liée aux valeurs proposées [Fischer 1983] Le consensus

a deux terms primitifs, proposer(v) et décider (v), ó v est une valeur tiréed'un ensemble de valeurs proposées possibles Quand un processus s'exécuteproposer(v), nous disent qu'il propose v ; de la même façon, quand un pro-cessus s'exécute décider(v), nous disent qu'il décide le v

Le consensus est spécié à l'aide de trois propriétés :

Accord : Si deux processus corrects décident, ils décident sur la mêmevaleur

Validité : Si un processus correct décide, sa valeur de décision est une desvaleurs initiales

Terminaison : Tous les processus corrects décident

Intégrité : Aucun processus décide 2 fois sur une même valeur

3.3.2 Variances

Il existe diverses variantes des spécications On peut faire diverses phothèse de défaillances sur les processus et sur le système de communication

Dans le système synchrone, les consensus savent les bornes des rounds

et ils ont les mêmes bornes par la période du temps Mais dans le systèmeasynchrone, les processus ne savent pas de bornes des rounds, et ils ont lesbornes diérentes

Fig 3.1  Système synchrone

Fig 3.2  Système asynchrone

Simple

Dans le consensus simple, on ne s'intéresse qu'aux processus corrects.Ses décisions deraient être les mêmes et diérentes de celles des processus enpannes

Uniforme

Dans le consensus uniforme, si un processus p fait la décision d, alors toutprocessus correct q fait la décision d C'est-à-dire, dans le système, s'il exist

un process an panne et avant de tomber en panne, ce processus pourrait faire

la décision ou faire rien Cette propriété assure que cette décision devrait être

la même avec ce-la des tous les processus correct

Hiérarchique

Les processus se classent 1,2, ,N

Au round kieme, le processus kieme a le droit d'annoncer la décision posal aux autres processus qui a le rang plus que k Après N rounds, tous lesprocessus commencent à décider réellement Ça demande toujours N roundspour avoir un accord.

pro-Fig 3.3  La solution hiérarichique

3.3.3 Consensus en l'absence de pannes

1 La solution avec un coordinateur

Un coordinateur est utilisé comme un processus central qui collecte tousles proposals et décider ce qui est la décision pour le système :

- Chaque processus pi envoie sa valeur vi à un coordinateur spécié àl'avance

- Quand le coordinateur a reçu toutes les valeurs vi, il choisit une de cesvaleurs, soit d (sur un critère quelconque)

- Le coordinateur envoie d à tous les pi

- Après la réception, chaque pi décide d

En communication asynchrone, tous auront décidé en temps ni mais nonborné

2 La solution symétrique

Cette méthode est très redondante dans ce cas simple, mais utile pourpréparer la suite :