Protocole Diffussion 2009-2 PDF

Protocoles de Diffusion
Algorithmique rpartie avance - ARA

Master2
Luciana Arantes
22/10/09
ARA: Protocoel de Diffusion
Motivation (1)
Dans certaines situations, les processus d'un systme rparti (ou un sousensemble de ces processus) doivent tre adresss comme un tout.
S1
P2
S2
P1
mise
jour
rsultat
P3
S3
S4
P5
P4
S5
Application de calcul parallle

Serveur rpliqu
22/10/09
Motivation (2)
P1
calcul
calcul
calcul
(attente rsultat P2)
calcul
calcul
erreur dtecte
calcul
calcul
calcul
P2
P3
Application de calcul parallle : si un message est perdu, le calcul s'arrte.
mise jour
C1
v=1
v=2
C2
v=2
P1
v=1
P2
v=2
P3
Serveur rpliqu : si les messages ne sont pas reus dans le mme ordre sur tous les processus, ils
sont incohrents.
22/10/09
Diffusion : Dfinition
Un processus metteur envoie un message un

groupe de processus.
22/10/09
Groupe : ensemble de processus (les membres du groupe)

auxquels on s'adresse par des diffusions, et non par des
envois point point.
Diffusion : primitives
Primitives de diffusion utilises par le processus

p:
broadcast (m) : le processus p diffuse le message m au

groupe.
deliver (m) : le message m est dlivr au processus p.
La diffusion est ralise au dessus d'un systme

de communication existant.
22/10/09
Architecture
processus application
broadcast(m)
deliver(m)
processus application
broadcast(m)
Communication de groupe
send(m)
recv(m)
deliver(m)
Communication de groupe
send(m)
recv(m)
rseau communication
22/10/09
Modle d'implmentation
Les messages ne sont pas directement reus par

l'application : ils sont reus par recv(m), mis en
attente, traits puis dlivrs l'application par
deliver(m).
broadcast(m)
deliver(m)
message diffus mis
librairie
file d'attente
send(m, p1)
Objectif : implmenter des

primitives boradcastX() et deliverX()
qui garantissent la proprit X.
code applicatif
Les messages sont diffuss par broadcast(m) qui n'est pas

atomique en pratique : elle s'appuie sur la primitive d'envoi
point point send(m, p).
recv(m)
send(m, pn)
message diffus reu
22/10/09
processus
Diffusion: primitives (2)
Le message envoy chaque processus est le mme, mais le nombre et

l'identit des destinataires est masqu l'metteur, qui les dsigne par
leur groupe d'appartenance. On assure ainsi la transparence de
rplication.
P2
P1
m
m
P5
P5 excute broadcast (m)
22/10/09
P3
P4
Groupe (1)
Un groupe peut tre :
ferm : broadcast(m) ne peut tre appel que par un membre du groupe
ouvert : broadcast(m) peut tre appel par un processus extrieur au groupe
interdit
possible
P2
P2
P1
P1
P3
P3
P5
P5
P4
P4
G
possible
Groupe ouvert
Groupe ferm
22/10/09
Groupe (2)
Un groupe peut tre :
statique : la liste des membres du groupe est fixe et dtermine au dpart
dynamique : les processus peuvent rejoindre ou quitter le groupe volontairement par
l'intermdiaire d'un service de gestion de groupe
P2
quitter()
P1
P3
P5
P5
P3
P4
G
rejoindre(G)
Groupe dynamique
22/10/09
10
Problmes
Les processus peuvent tomber en panne, notamment au

milieu d'un envoi multiple de message
L'ordre de rception des messages sur les diffrents
processus destinataires n'est pas garanti (entrelancement
d aux latences rseau variables)
Problmes rsoudre
assurer des proprits de diffusion :

garantie de remise des messages

garantie d'ordonnancement des messages reus
22/10/09
11
Communications et Processus
Communications

Point point
Tout processus peut communiquer avec tout les autres
Canaux fiables : si un processus p correct envoie un message m
processus correct q, alors q finit par le recevoir ("eventually
receives").
Processus
Susceptibles de subir de pannes franches. Suite une panne franche,

un processus s'arrte dfinitivement : on ne considre pas qu'il puisse
ventuellement redmarrer.
Un processus qui ne tombe pas en panne sur toute une

excution donne est dit correct, sinon il est dit fautif.
22/10/09
12
Proprits des diffusions (1)

Garantie de remise

Diffusion Best-effort (Best-effort Broadcast)

Diffusion Fiable (Reliable Broadcast)
Diffusion Fiable Uniforme (Uniform Reliable Broadcast).
Garantie d'ordonnancement
les messages sont dlivrs dans un ordre :

FIFO
Causal
Total
Les garanties de remise et d'ordre sont orthogonales
22/10/09
13
1. Garantie de Remise: Best Effort

Diffusion Best-effort
Garantie la dlivrance d'un message tous les processus

corrects si l'metteur est correct.
Problme : pas de garantie de remise si l'metteur tombe
en panne
P1
correct
P2
fautif
!
P3
correct
P4
correct
P2 tombe en panne avant d'envoyer le messages P3

22/10/09
14
Diffusion Best-Effort
Spcification
Validit : si p1 et p2 sont corrects alors un message m
diffuser par p1 finit par tre dlivr par p2.
Intgrit: un message m est dlivr au plus une fois et
seulement s'il a t diffus par un processus.
Algorithme
Processus P :
BestEffort_broadcast (m)
. envoyer m tous les processus y compris p
upon recv(m) :
BestEffort_deliver(m)
22/10/09
/* groupe ferm */
/* dlivrer le message */
15
2. Garantie de Remise : Fiable

Diffusion Fiable (Reliable Broadcast)

si l'metteur du message m est correct, alors tous les

destinataires corrects dlivrent le message m.
si l'metteur du message m est fautif, tous ou aucun
processus corrects dlivrent le message m.
P1
correct
P2
fautif
P3
correct
impossible
22/10/09
Diffusion fiable
16
Diffusion Fiable spcification (1)

Spcification
Validit : si un processus correct diffuse le message m,

alors tous les processus corrects dlivrent m
Accord : si un processus correct dlivre le message m,
alors tous les membres corrects dlivrent m
Intgrit: Un message m est dlivr au plus une fois
tout processus correct, et seulement s'il a t diffus par
un processus.
22/10/09
17
Diffusion Fiable : principe

Si un processus correct dlivre le message diffus m, alors tout processus
correct dlivre aussi m
P1
m1
P2
crash
m2
P3 ne recevra pas m2 alors que P1 si
P3
22/10/09
18
Diffusion Fiable : principe
Implmentation possible : sur rception d'un message diffus par un autre

processus, chaque processus rediffuse ce message avant de le dlivrer.
P1
m1
P2
m2
P3
22/10/09
19
Diffusion Fiable : algorithme

Processus P :
Chaque message m est estampill de faon unique

avec :
sender (m) : l'identit de l'metteur
seq#(m) : numro de squence
Variable locale :
rec = ;
Real_broadcast (m)
estampiller m avec sender(m) et seq#(m);
envoyer m tous les processus y compris p
upon recv(m) do
if m rec then
rec = { m }
if sender(m) != p then
envoyer m tous les processus sauf p
Real_deliver(m) /* dlivrer le message */
22/10/09
20
10
Diffusion Fiable : discussion

Avantages :
Inconvnients :
la fiabilit ne repose pas sur la dtection de la panne de

l'metteur
l'algorithme est donc valable dans tout modle temporel
l'algorithme est trs inefficace : il gnre n (n 1) envois
par diffusion
ce qui le rend inutilisable en pratique
Remarques :
l'algorithme ne garantit aucun ordre de remise
22/10/09
21
Diffusion Fiable
Problme :
aucune garantie de dlivrance est offerte pour les

processus fautifs
Exemple :
Real_broadcastF(m)
Real_deliver(m)
crash
P1
!
m1
P2
P3
P1 dlivre m et aprs il crash ; P2 et P3 ne reoivent pas m

P1 avant sa dfaillance peut excuter des actions irrversibles comme
consquence de la dlivrance de m
22/10/09
22
11
3: Garantie de Remise fiable uniforme

Diffusion Fiable Uniforme (Uniform Reliable

Broadcast)
22/10/09
Si un message m est dlivr par un processus (fautif ou

correct), alors tout processus correct finit aussi par
dlivr m.
23
Diffusion Fiable Uniforme

Proprit d'uniformit
Une proprit (accord, intgrit) est dite uniforme si elle

s'applique tous les processus : corrects et fautifs.
Diffusion Fiable Uniforme

22/10/09
Validit : si un processus correct diffuse le message m,

alors tous les processus corrects dlivrent m
Accord uniforme : si un processus (correct ou fautif)
dlivre le message m, alors tous les membres corrects
dlivrent m.
Intgrit uniforme: Un message m est dlivr au plus une
fois tout processus (correct ou fautif), et seulement s'il
a t diffus par un processus.
24
12
Diffusion Fiable Temporise

Diffusion fiable temporise = diffusion fiable +

borne

Systme de communication synchrone

Borne : il existe une constante telle que si un message
m est diffus l'instant t, alors aucun processus correct ne
dlivre m aprs le temps t+ .
22/10/09
25
Garantie d'ordre (1)

Ordre Total
Ordre FIFO
Les messages sont dlivrs dans le mme ordre tous leurs

destinataires.
si un membre diffuse m1 puis m2, alors tout membre correct qui
dlivre m2 dlivre m1 avant m2.
Ordre Causal
si broadcast(m1) prcde causalement broadcast (m2), alors

tout processus correct qui dlivre m2, dlivre m1 avant m2.
Observations :
- La proprit d'ordre total est indpendante de l'ordre d'mission
- Les proprits d'ordre FIFO et Causal sont lies l'ordre d'mission
22/10/09
26
13

Exemple
F2
C2
T1
P1
P2
P3
F1
F3
C1
Ordre FIFO
C3
T2
Ordre causal
22/10/09
Ordre total
27

Remarques :
22/10/09
une diffusion causale est ncessairement FIFO (la

diffusion causale peut tre vue comme une gnralisation
de l'ordre FIFO tous les processus du groupe)
L'ordre FIFO et l'ordre causal ne sont que des ordres
partiels : ils n'imposent aucune contrainte sur l'ordre de
dlivrance des messages diffuss concurremment
l'ordre total n'a pas de lien avec l'ordre FIFO et l'ordre
causal : il est la fois plus fort (ordre total des messages
dlivrs) et plus faible (aucun lien entre l'ordre de
diffusion et l'ordre de dlivrance)
28
14
Garantie d'ordre - Exemple utilisation (4)

Ordre total : permet de maintenir la cohrence des rpliques d'un serveur en prsence
d'crivains multiples.
v=1
C1
v=2
C2
v=1
P1
v=1
P2
v=1
P3
Ordre causal : permet de prserver faible cot l'enchanement d'oprations logiquement

lies entre elles.
P1
insrer(o1)
insrer(o1)
P2
supprimer(o1)
P3
supprimer(o1)
Ordre non causal

22/10/09
Ordre causal
29
Garantie d'ordre - Exemple utilisation (5)

Ordre FIFO : permet de maintenir la cohrence des rpliques d'un serveur en prsence d'un
crivain unique.
C1
C2
x=1
x=2
y=2
x=2
P1
x=2
P2
x=2
P3
Les trois garanties d'ordre FIFO, causal et total sont plus ou moins coteuses implmenter :
choisir celle juste ncessaire l'application vise.
22/10/09
30
15
Types de Diffusion Fiable (1)

Diffusion FIFO = Diffusion fiable + Ordre FIFO

Diffusion Causal (CBCAST) = Diffusion fiable +
Ordre Causal
Diffusion Atomique (ABCAST) = Diffusion fiable +
Ordre Total
Diffusion Atomique FIFO = Diffusion FIFO +
Ordre Total
Diffusion Atomique Causal = Diffusion Causal +
Ordre Total
22/10/09
31
Types de Diffusion Fiable (2)

Diffusion
fiable
ordre total
Diffusion
atomique
ordre FIFO
ordre FIFO
Diffusion
FIFO
ordre total
Diffusion
Atomique
FIFO
ordre causal
ordre causal
Diffusion
Causal
ordre total
Diffusion
Atomique
Causal
Relation entre les primitives de diffusion [Hadzilacos & Toueg]

22/10/09
32
16
Diffusion FIFO - motivation

Dans la diffusion fiable il n'y a aucune

spcification sur l'ordre de dlivrance des
messages.
V=1
V=2
V=2
serveur
V=1
V=2
!
V=1
client
22/10/09
33
Diffusion FIFO
Diffusion FIFO = diffusion fiable + ordre FIFO

22/10/09
Ordre FIFO : si un membre diffuse m1 puis m2, alors tout

membre correct qui dlivre m2 dlivre m1 avant m2.
Ayant un algorithme de diffusion fiable, il est possible de
le transformer dans un algorithme de diffusion FIFO
34
17
Diffusion FIFO algorithme (1)

Processus p :
Variable locale :
pendMsg = ;
next [ N ] = 1 pour tous processus;
FIFO_broadcast (m)
Real_broadcast(m);
/* message pas encore dlivr */

/*seq# du prochain message de q que p doit dlivrer */
/*m estampill avec seq# */
upon Real_deliver(m) do
s = sender (m);
pendMsg = { m }
while ( m' PendMsg : sender(m') =s and seq#(m') = next[s]) do
FIFO_delivrer(m) /* dlivrer le message */
next[s]++;
pendMsg -= { m };
22/10/09
35
Diffusion FIFO algorithme (2)

FIFO_broadcast (m1)
FIFO_broadcast (m2)
m2
FIFO_broadcast (m3)
m3
m1
recv(m1)
Real_deliver(m1)
FIFO_deliver(m1)
q
next[p] =1
pendMsg ={ }
22/10/09
recv(m3)
Real_deliver(m3)
next[p] =2
pendMsg ={ }
next[p] =2
pendMsg ={3}
recv(m2)
Real_deliver(m2)
FIFO_deliver(m2)
FIFO_deliver (m3)
next[p] =4
pendMsg ={}
36
18
Diffusion Causal - CBCAST

Diffusion Causal = diffusion fiable + ordre Causal

Objectif : dlivrer les messages dans l'ordre causal de leur

diffusion.
Ordre causal : si broadcast(m1) prcde causalement
broadcast (m2), alors tout processus correct qui dlivre m2,
dlivre m1 avant m2.

broadcastp(m1) broadcastq(m2) deliverp(m1) deliverq(m2)
Causal Order FIFO order

Fifo Order Causal Order
22/10/09
37
Diffusion Causal
broadcastp(m1) broadcastq(m2) deliverp(m1) deliverq(m2)
P1
d1
m1
P2
P3
m2
m2 est dlivr trop tt sur P2 : il

aurait d attendre m1 puisque d1
d2
d2
Un algorithme de diffusion FIFO peut tre transform dans un algorithme de

diffusion causal :
transporter avec chaque message diffus l'historique des messages qui le
prcdent causalement.
22/10/09
38
19
Diffusion Causal algorithme

Processus p :
Variable locale :
seqMsg = vide;
/* sequence de messages que p a dlivr depuis sa diffusion prcdente */
delv = ; /* messages dlivres */
Causal_broadcast (m)
FIFO_broadcast(seqMsg m);
/* diffuser tous les messages dlivrs depuis la diffusion

prcdente + m */
seqMsg = vide;
upon FIFO_deliver(m1,m2,.. mn) do

for i=1.. n do
if mi delv then
Causal_delivrer(mi)
delv = { mi }
seqMsg = mi
22/10/09
/* dlivrer le message */
/*ajouter mi la fin de la seqMsg */
39
Diffusion Causal algorithme

seqMsg = {m1}
deliv = {m1}
P1
<m1> Causal_deliver (m )
1
<m1>
<m1>
P2
<m1,m2>
<m1,m2>
P3
Causal_deliver (m1)
seqMsg = {m1}
deliv = {m1}
Causal_deliver (m1)
Causal_deliver (m2)
ignor
seqMsg = {m1,m2}
deliv = {m1,m2}
m2
Causal_deliver (m2)
<m1,m2>
seqMsg = {m1,m2}
deliv = {m2}
Avantage :
La dlivrance d'un message n'est pas ajourne en attente d'une condition
Inconvnient
Taille des messages
22/10/09
40
20
Diffusion Causal algorithme avec horloges

vectorielles (sans garantie de remise)
Historique de messages peut tre reprsent au moyen d'une
d'horloge vectorielle
Processus P :
Variables locales :
HV[N] = {0, 0, , 0}
FA =
HV[k]m venant de Pj reprsente :

k = j : le nombre de messages diffuss par Pj
k j : le nombre de diffusions de Pk dlivres par Pj
avant diffusion de m.
Causal_Broadcast(m)
HV[i] += 1
estampiller m avec HV;
envoyer m tous les processus y compris p
22/10/09
Isis - Birman 91
41

vectorielles (sans garantie de remise)
Upon recv(m, HV[]m) :
s = sender (m);
FA.queue(< m, HV[]m >)
delay delivery of m until
(1) HV[s]m = HV[s]p + 1 and (2) HV[k]m HV[k]p pour tout k; k s
// D'autres rceptions se produisent pendant l'attente. On attend d'avoir dlivr :
// 1- toutes les diffusions prcdentes effectues par s,
// 2- toutes les diffusions dlivres par s avant la diffusion de m
FA.dequeue(< m, HV[]m >)
deliver(m);
HV[s]p +=1;
(1) : assure que p a dlivr tous les messages de s provenant de s qui prcdent m
(2) : assure que p a dlivr tous les messages dlivrs par s avant que celui-ci envoie m
22/10/09
42
21

vectorielles - Exemple
m1
P1
P2
0
0
0
1
0 m1
0
0
0
0
m1
0
0
0
P3
1
m2 0
1
1
0
0
1
0 m2
1
m1
P2
P3
m2
1
0
0
1
0
1
m1
m2
m2
m1
P1
m2
m2
0
0
0
1
0
0
0
0
0
m1
0
0
1
0
0
0
et
m1
m2
m1
1
m2 0
1
1
0
0
1
0
1
m1
m2
m
ARA: Protocoel de2 Diffusion
22/10/09
1
0
1
m1
43
Diffusion Atomique - ABCAST

Diffusion atomique = diffusion fiable + ordre total

Tous les processus corrects dlivrent le mme ensemble de messages

dans le mme ordre.
Ordre Total : si les processus corrects p et q dlivrent tous les deux
les messages m et m', alors p dlivre m avant m' seulement si q dlivre
m avant m'.
Exemple d'une diffusion pas atomique
C1
C2
m1
m2
P1
!
P2
m1 est dlivr aprs m2 sur P2, alors que

c'est l'inverse sur P1 et P3
P3
22/10/09
44
22

Rsultat fondamental : Dans un systme asynchrone avec pannes
franches, la diffusion atomique est quivalent au consensus.
Consensus impossible dans un systme
asynchrone avec pannes franches
Diffusion atomique impossible dans un

systme asynchrone avec pannes franches
. Si on dispose d'un algorithme de diffusion atomique, on sait raliser le

consensus
Chaque processus diffuse atomiquement sa valeur propose tous les processus
Tous les processus reoivent le mme ensemble de valeurs dans les mme ordre
Ils dcident la premire valeur
Si on dispose d'un algorithme de consensus, on sait raliser la diffusion

atomique
Diffusion Atomique
Consensus
Chandra & Toueg 1996
22/10/09
45

Remarques :
ABCAST n'est pas ralisable dans un systme asynchrone

si on suppose l'existence de fautes (d'aprs FLP).
ABCAST est ralisable (n nodes):
22/10/09
Avec un dtecteur de pannes de classe P ou S en tolrant n-1

pannes
Avec dtecteur de pannes de classe S en tolrant n/2 -1
pannes
Avec un protocole de diffusion fiable temporise en utilisant
des hypothse de synchronisme.
46
23
Diffusion Atomique - algorithmes

Un protocole ABCAST doit garantir l'ordre de remise de

messages et tolrer les dfaillances
L'ordre d'un protocole ABCAST peut tre assur par :
Un ou plusieurs squenceurs
squenceur fixe
squenceur mobile
Les metteurs
base de privilge
Les rcepteurs
Accord des rcepteurs
Remarques: les algorithmes prsents la suite ne traitent pas les pannes
22/10/09
47
Diffusion totalement ordonne : Squenceur fixe
squenceur
m,seq#
m
m,seq#
m,seq#
metteur
22/10/09
48
24
Diffusion totalement ordonne : Squenceur fixe
Principe :
Un processus, le squenceur, est choisi parmi tous les processus

Responsable de l'ordonnancement des messages
metteur envoie le message m au squenceur
Squenceur attribue un numro de squence seq# m
Squenceur envoie le message tous les processus.
22/10/09
49
Squenceur fixe - algorithme

Processus P :
Variables locales :
nextdelv = 1;
pend = ;
Squenceur :
intit :
seq#=1;
upon revc(m) do
send (m,seq#) to processus
seq#++;
22/10/09
Emetteur :
OT_broadcast (m)
send m au squenceur;
Destinateur :
upon revc(m) do
pend = {m}
while ( (m',seq#') pend : seq#'=nextdelv) do
OT_deliver (m')
nextdelv++;
pend -= {m'}
50
25
Diffusion totalement ordonne : Squenceur mobile
squenceur
m,seq#
m
m
metteur
destinateur
m,seq#
jeton
squenceur
m,seq#
destinateur
squenceur
destinateur
squenceur
22/10/09
51
Diffusion totalement ordonne : Squenceur mobile

Principe

Avantages
Un groupe de processus agissent successivement comme squenceur

Un message est envoy tous les squenceurs.
Un jeton circule entre les squenceurs, contenant :

un numro de squence

Liste de messages dj squencs
Lors de la rception du jeton, un squenceur :

attribue un numro de squence tous les messages pas encore squencs
et envoie ces messages aux destinateurs

Ajoute les messages envoys dans la liste du jeton
rpartition de charge
Inconvnients

22/10/09
Taille jeton
cot circulation du jeton
52
26
Squenceur mobile - algorithme

Variables locales :
nextdelv = 1;
pend = ;
Squenceur :
intit :
rec = ;
if (p= s1)
token.seq# = 1
Emetteur :
token.liste = ;
OT_broadcast (m)
upon revc(m) do
send m tous les squenceurs;
rec = {m}
upon recv(token) do
Destinateur :
for each m' in rec \ token.liste do
upon revc(m) do
send (m',token.seq#) tous les
pend = {m}
destinateurs
token.seq#++;
OT_deliver (m')
token.liste = {m}
send (token) au prochain squenceur
nextdelv++;
pend -={m'}
22/10/09
53
Diffusion totalement ordonne : base de

priorit
metteur
m,seq#
destinateur
metteur
m,seq#
jeton
m,seq#
destinateur
metteur
destinateur
metteur
22/10/09
54
27
Diffusion totalement ordonne : base de

priorit
Principe

Un jeton donne le droit d'mettre

Jeton circule entre les metteurs contenant le numro de squence du
prochain message envoyer.
Lorsqu'un metteur veut diffuser un message, il doit attendre avoir le
jeton
attribue un numro de squence aux messages diffuser
envoie le jeton aux prochains metteurs
Inconvnients
Ncessaire de connatre les metteurs (pas adquat pour de groupe

ouvert)
Pas trs quitable : un processus peut garde le jeton et diffuser un
nombre important de messages en empchant les autres de le faire
22/10/09
55
Diffusion totalement ordonne : base

de priorit
Variables locales :
nextdelv = 1;
pend = ;
Emetteur :
intit :
send_pend = ;
if (p=s1)
token.seq# = 1
procedure OT_broadcast (m)
send_pend = {m}
Destinateur :
upon recv(token) do
upon revc(m) do
for each m' in send_pend do
pend = { m}
send (m',token.seq#) tous les
destinateurs
OT_deliver (m')
token.seq#++;
nextdelv++;
send_pend = ;
pend -={m'}
send (token) au prochain metteur
22/10/09
56
28
Diffusion totalement ordonne : accord rcepteurs
Principe
Les processus se concertent pour attribuer un numro de

squence chaque message. Chaque diffusion ncessite
deux phases :
diffusion du message et collecte des propositions de

numrotation
choix d'un numro dfinitif et diffusion du numro choisi
22/10/09
57
Accord rcepteurs
ns = max( nsi )
E
<m, id(m)>
P1
<id(m), ns1>
<id(m), ns>
<id(m), ns2>
<id(m), ns3>
P2
P3
Les numros proposs sont <date logique rception, identit rcepteur>

pour assurer un ordre total. Chaque processus maintient une file d'attente
des messages en attente de numrotation dfinitive, trie de faon
croissante sur les numros.
22/10/09
58
29
Accord rcepteurs : algorithme

E diffuse le message m au groupe :

sur rception de m, Pj attribue m son numro de rception

provisoire, le marque non dlivrable, et l'insre dans sa file d'attente
puis Pj renvoie E le numro provisoire de m comme proposition de
numro dfinitif
quand E a reu tous les numros proposs, il choisit le plus grand
comme numro dfinitif et le rediffuse
sur rception du numro dfinitif, Pj rordonne m dans sa file et le
marque dlivrable
puis Pj dlivre tous les messages marqus dlivrable situs en tte de
la file d'attente
Birman - Joseph 87
22/10/09
59
m3
m1
m2
Etape 2
Etape 3
Etape 4
rception date dfinition m3
Etape 1
Accord rcepteurs : exemple
m2
m1
m3
P2
P3
m1
m3
P1
m2
P1, P2 et P3 diffusent simultanment les trois messages m1, m2 et m3 (seuls les messages de
l'tapes 1 sont reprsents).
Note : il s'agit d'un exemple d'excution ; la date dfinitive d'un message n'arrive pas
ncessairement dans le mme laps de temps sur tous les processus, ni dans le mme ordre
pour les diffrents messages.
22/10/09
60
30
Accord rcepteurs : exemple (cont.)

Etape 1 : rception des messages et proposition de numrotation
FA P1
m3
15.1
N
m1
16.1
N
FA P2
m2
16.2
N
m2
17.1
N
m1
17.2
N
FA P3
m1
17.3
N
m3
18.2
N
m3
18.3
N
m2
19.3
N
Etape 2 : rception de la date de dfinitive de m1 : 17.3

FA P1
m3
15.1
N
m2
17.1
N
FA P2
m1
17.3
D
m2
16.2
N
m1
17.3
D
FA P3
m1
17.3
D
m3
18.2
N
m3
18.3
N
m2
19.3
N
m1 est dlivr sur P3

22/10/09
61
Accord rcepteurs : exemple (cont.)

FA P1
m3
15.1
N
m1
17.3
D
FA P2
m2
19.3
D
m1
17.3
D
m3
18.2
N
FA P3
m2
19.3
D
m3
18.3
N
m2
19.3
D
m1 est dlivr sur P2

FA P1
m1
17.3
D
m3
18.3
D
FA P2
m2
19.3
D
m1, m3 puis m2
dlivrs sur P1
22/10/09
m3
18.3
D
m2
19.3
D
m3 puis m2
dlivrs sur P2
FA P3
m3
18.3
D
m2
19.3
D
m3 puis m2
dlivrs sur P3
62
31
Diffusion totalement ordonne

tolrance aux fautes
Quelques mcanismes :

Dtecteurs de dfaillance
Redondance
Exemple : squenceur
Stabilit des messages

Un message est k-stable s'il a t reu par k processus.

Pertes de messages
22/10/09
f dfaillances : un messages (f+1)-stable a t reu par au

moins 1 processus correct. Sa dlivrance peut tre garantie.
Numrotation des messages.

63
Bibliographie

X. Dfago and A. Schiper and P. Urban Total order broadcast and multicast
algorithms: Taxonomy and survey, ACM Comput. Surv., 36(4):372421.
K.Birman, T. Joseph. Reliable communication in presence of failures. ACM
Transactions on Computer Systems, Vol. 5, No. 1, Feb. 1987
K. Birman and R. Cooper. The ISIS Project: Real Experience with a Fault
Tolerant Programming System. Operating Systems Review, Apr. 1991, pages
103-107.
K. Birman, A. Schiper and P. Stephenson. Lightweight Causal and Atomic Group
Multicast. ACM Transactions on Computer Systems, Aug. 1991, (3):272-314.
R. Guerraoui, L. Rodrigues. Reliable Distributed Programming, Springer, 2006
V. Hadzilacos and S. Toueg. A Modular Approach to Fault-tolerant Broadcasts
and Related Problems. Technical Report TR94-1425. Cornell University.
T.Chandra and S.Toueg. Unreliable failure detectors for reliable distributed
systems, Journal of the ACM,Vol.43. No.2, 1996, pages 225-267.
22/10/09
64
32

Protocole Diffussion 2009-2 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Protocole Diffussion 2009-2 PDF

Uploaded by

Copyright:

Available Formats

Protocoles de Diffusion

Algorithmique rpartie avance - ARA

ARA: Protocoel de Diffusion

Application de calcul parallle

ARA: Protocoel de Diffusion

(attente rsultat P2)

(attente rsultat P3)

(attente rsultat P2)

ARA: Protocoel de Diffusion

Un processus metteur envoie un message un

Groupe : ensemble de processus (les membres du groupe)

ARA: Protocoel de Diffusion

Primitives de diffusion utilises par le processus

broadcast (m) : le processus p diffuse le message m au

La diffusion est ralise au dessus d'un systme

ARA: Protocoel de Diffusion

ARA: Protocoel de Diffusion

Les messages ne sont pas directement reus par

message diffus mis

Objectif : implmenter des

Les messages sont diffuss par broadcast(m) qui n'est pas

ARA: Protocoel de Diffusion

Diffusion: primitives (2)

Le message envoy chaque processus est le mme, mais le nombre et

P5 excute broadcast (m)

ARA: Protocoel de Diffusion

ARA: Protocoel de Diffusion

ARA: Protocoel de Diffusion

Les processus peuvent tomber en panne, notamment au

assurer des proprits de diffusion :

garantie de remise des messages

ARA: Protocoel de Diffusion

Susceptibles de subir de pannes franches. Suite une panne franche,

Un processus qui ne tombe pas en panne sur toute une

ARA: Protocoel de Diffusion

Proprits des diffusions (1)

Diffusion Best-effort (Best-effort Broadcast)

les messages sont dlivrs dans un ordre :

Les garanties de remise et d'ordre sont orthogonales

ARA: Protocoel de Diffusion

1. Garantie de Remise: Best Effort

Garantie la dlivrance d'un message tous les processus

P2 tombe en panne avant d'envoyer le messages P3

ARA: Protocoel de Diffusion

2. Garantie de Remise : Fiable

Diffusion Fiable (Reliable Broadcast)

si l'metteur du message m est correct, alors tous les

ARA: Protocoel de Diffusion

Diffusion Fiable spcification (1)

Validit : si un processus correct diffuse le message m,

ARA: Protocoel de Diffusion

Diffusion Fiable : principe

P3 ne recevra pas m2 alors que P1 si

ARA: Protocoel de Diffusion

Diffusion Fiable : principe

Implmentation possible : sur rception d'un message diffus par un autre

ARA: Protocoel de Diffusion

Diffusion Fiable : algorithme

Chaque message m est estampill de faon unique

ARA: Protocoel de Diffusion

Diffusion Fiable : discussion

la fiabilit ne repose pas sur la dtection de la panne de

l'algorithme ne garantit aucun ordre de remise

/m estampill avec seq# /