Le comunicazioni ordinate
Comunicazioni Ordinate
E’ importante (e utile) definire delle primitive di comunicazione che diano qualche garanzia sull’ordine di consegna dei messaggi inviati all’interno di un gruppo di processi
Vedremo le seguenti: Comunicazione che rispetta l’ordine FIFO di invio dei messaggiComunicazione che rispetta l’ordine causaleComunicazione che rispetta un ordine totale
Comunicazione in un gruppo di processi
Comunicazione di gruppo: gruppo definito di processi. Primitive di gruppo che garantiscono vari tipi di reliability:
(1) Best-effort broadcast(2) (Regular) reliable broadcast (3) Uniform (reliable) broadcast
Rivediamo la specifica del (Regular) reliable brodcast, (d’ora in poi solo Reliable broadcast) :
SafetySafety. Integrity (No Duplication, No Creation): per qualsiasi messaggio m, ogni processo corretto consegna m al più una volta, e solo se m è stato precedentemente inviato in broadcast da un processo mittente
LivenessLiveness:Validity: se un processo corretto invia in broadcast un messaggio m, allora tutti i processi corretti alla fine consegnano m.Agreement : se un processo corretto consegna un messaggio m, allora tutti i processi corretti alla fine consegnano m.
Utilità della comunicazione ordinata
Nel Reliable broadcast non c’è alcun requisito sull’ordine in cui i messaggi sono consegnati
Per alcune applicazioni ciò può portare ad “anomalie”...
Esempio: sistema di prenotazione aerea. L’anomalia consiste in una consegna di un msg di cancellazione di una prenotazione che il server non ha ancora registrato!
tclient
server
“reserve” “cancel”
“Prices 15% off”
FIFO Broadcast\specificaQual è la soluzione? Occorre che i messaggi di broadcast inviati dallo stesso mittente vengano consegnati nello stesso ordine in cui i messaggi sono stati inviati.
A questo scopo introduciamo una nuova primitiva di comunicazione di gruppo in grado di implementare questa soluzione: FIFO Broadcast
La specifica del FIFO broadcast è costituita dalle proprietà viste per il Reliable broadcast alle quali si aggiunge un’altra proprietà di SafetySafety per catturare la nozione di ordine:
FIFO Order: se un processo invia in broadcast un messaggio m prima di un messaggio m’, allora nessun processo corretto consegna m’ a meno che non abbia precedentemente consegnato m.
FIFO Broadcast = Reliable Broadcast + FIFO Order
Each process q holds: S p
a count of messages broadcast by p Rp the sequence number of the latest message sent by p and delivered by q
For p to FO-multicast a message to g, it piggybacks S p
on the message, rbBroadcasts it and increments S p
by 1
On receipt of a message from q sent by p with sequence number S, p checks whether
S = Rp + 1. If so, q FO-delivers it
if S > Rp + 1 then q places message
in hold-back queue until intervening messages have been delivered. (note that rbBroadcast does eventually deliver messages unless the sender crashes)
Messageprocessing
Delivery queueHold-back
queue
deliver
Incomingmessages
When delivery guarantees aremet
FIFO Broadcast\algoritmo
Utilità della comunicazione ordinata(2)
Prof.
Student 2
m1: “Fri exam cancelled”
Student 1m2:
“let’s party on Thu night”
m3: “but we have an exam on Fri!”
Causal Order FIFO Order, ma FIFO OrderCausal OrderQuindi, Causal Order = FIFO Order + ?
Causal Broadcast\specifica
La specifica del Causal broadcast è costituita dalle proprietà viste per il Reliable broadcast alle quali si aggiunge un’altra proprietà di SafetySafety per catturare la nozione di ordine:
Causal Order: se il broadcast di un messaggio m precede causalmente il broadcast di un messaggio m’, allora nessun processo corretto consegna m’ a meno che non abbia precedentemente consegnato m.
Causal Broadcast = Reliable Broadcast+Causal Order
Causal Broadcast\specifica
Causal Order = FIFO Order + Local Order.
Local Order: se un processo consegna un msg m prima di inviare in broadcast un msg m’, allora nessun processo corretto consegna m’ a meno che non abbia precedentemente consegnato m.
Esempio:
p
q
r
tm
m’
Viene ritardato e consegnato solo dopo la consegna di m
Causal Broadcast\implementazioni
Due implementazioniUn algoritmo blocking che usa vector clocks Un algoritmo non-blocking che usa il passato
p1
p2
p3
COBcast(m1)
CObcast(m2)
COBcast(m3)
m1
m2
m1,m2 , m3
COdelv(m1)
COdelv(m3)m2 già COdelivered!
COdelv(m1)
COdelv(m1)COdelv(m2)
COdelv(m2) COdelv(m3)
COdelv(m3)
COdelv(m2)scarta
IDEA DI BASE: PIGGYBACKING DEI
MESSAGGI che fanno parte del PASSATO
del msg inviato
Utilità della comunicazione ordinata(3)
Anche il Causal Order non è abbastanza forte per assicurare l’assenza di anomalieEs. Applicazione banking. Conto bancario replicato su due siti
R1
R2
A:£100
A:£100
Deposit £20
Add 10% interest
A:£120
A:£110
A:£132
A:£130
Sebbene le repliche siano inizialmente identiche alla fine sono inconsistenti anche se il Causal Order è soddisfatto (banalmente)
Qual è la soluzione? per garantire che le repliche siano sempre identiche, si deve assicurare che tutti gli update siano consegnati nel medesimo ordine anche quando non sono causalmente dipendenti.
A questo scopo introduciamo una nuova primitiva comunicazione di gruppo in grado di implementare questa soluzione : Total Order (Atomic) Broadcast
Atomic Broadcast\specifica
La specifica del Total Order broadcast è costituita dalle proprietà viste per il Reliable broadcast alle quali si aggiunge un’altra proprietà di SafetySafety per catturare la nozione di ordine:
Total Order: se due processi corretti p e q consegnano entrambi m ed m’, allora p consegna m prima di m’ se e solo se q consegna m prima di m’
Si noti che la proprietà di total order è una proprietà ortogonale rispetto a FIFO order e causal order. Quindi il total order non è una proprietà più forte rispetto alle altre due. Ad esempio tutti i processi potrebbero consegnare due messaggi, inviati dallo stesso processo, in ordine inverso rispetto a quello di invio.
Causal Atomic broadcast
Gerarchia delle Primitive di Broadcast
Reliable broadcast
FIFO broadcast
Causal broadcast
FIFO Atomic broadcast
Atomic broadcast
Total Order
Causal Order
Total Order
Total Order
FIFO Order FIFO Order
Local OrderCausal OrderLocal Order
Atomic Broadcast e Consenso
Si può realizzare il Consenso con l’atomic broadcast
Si può realizzare l’atomic broadcast con Consenso e reliable broadcast: il messaggio viene inviato in Reliable Broadcast, i processi riceventi propongono un numero di sequenza per il messaggio (in realtà per tutti quelli in coda non ancora ordinati) facendo partire un Consenso. Alla fine decideranno per la stessa sequenza di consegna per i messaggi.
Quindi si può dimostrare che l’Atomic Broadcast e il Consenso sono problemi equivalenti in un sistema con canali affidabili
Ciò significa che non esiste alcun algoritmo che soddisfa la specifica dell’atomic broadcast in un modello di sistema asincrono con guasti di tipo crash: FLP per ATOMIC BROADCAST!!
System model
Static set of processes Π = {p1 … pn}
Message passing over perfect channels (message exchanging between correct processes is reliable)AsynchronousCrash fault model for processesWe characterize the system in terms of its possible runs R
Rp1
p2
pn
TOcast(m)
m
m
m
TOdeliver(m)
crash
r
A few notation
Property P: predicate on the system, identifying a set of runs RP R
P P’ iff RP RP’
Specification S(P1,…,Pm): logical and of m properties, identifying a set of runs RS=RP1
∩ … ∩ RPm R
S → S’ iff RS RS’
RP RP’
RS RS’
RP1RPnRS
R
R
R
TO specifications
Total order specifications are usually composed by four properties, namely Validity, Integrity,Agreement, and Order. A Validity property guarantees that messages sent by correct processes will eventually be delivered at least by correct processes; An Integrity property guarantees that no spurious or duplicate messages are delivered; An Agreement property ensures that (at least correct) processes deliver the same set of messages; An Order property constrains (at least correct) processes delivering the same messages to deliver them in the same order.
TO specifications
Total Order Broadcast = S(V,I,A,O)V = ValidityI = IntegrityA = AgreementO = Order
Distinct specifications arise from distinct formulations of each property
uniform vs non-uniformA uniform property imposes restrictions on the behavior of (at least) correct processes on the basis of events occurred in some process
NUVUI
TO(A,O)
TO Specifications
Crash failure + Perfect channels NUV. if a correct process TOCAST a message m then some correct process will eventually deliver mUI. For any message m, every process p delivers m at most once and only if m was previously tocast by some (correct or not) process.
The Agreement property
(Uniform Agreement, UA) If a process (correct or not) todelivers a message m, then all correct processes will eventually todeliver m;(Non-uniform Agreement, NUA) If a correct process todelivers a message m, then all correct processes will eventually todeliver m
The Agreement property
Constrains the set of delivered messages
Correct processes always deliver the same set of messages MEach faulty process p delivers a set Mp
UA: Mp M
NUA: Mp can be s.t. Mp - M ≠
m2
m4
p1
p2
p3
m2m4
m1
m1
m3
m3
m3
m4
m1
m2
UAm4
p1
p2
p3
m2m4
m1
m1
m3
m3
m3
m4
m1
m2
m5
NUA
The Order property
Constrains the order of message deliveries and possibly the set of delivered messages
SUTO: if p delivers m<m’, q delivers m’ only after m
same ordersame prefix of the set of delivered messagesafter an omission, disjoint sets of delivered messages
WUTO: if p,q deliver m,m’, they get the same order
no restrictions on the set of delivered messages
p1
p2
p3
m2
m2
m2
m1
m1
m1m4
m3
m3
m7
m6
m5
p1
p2
p3
m2
m2m1
m1
m1m4
m3
m3
m7
m6
m5
SUTO WUTO
The Order property (2)SUTO and WUTO are uniformThey both have a non-uniform counterparts: SNUTO and WNUTO (Strong Non-uniform Total Order, SNUTO). If some correct process todelivers some message m before message m', then a correct process todelivers m‘ only after it has todelivered m.
(Weak Non-uniform Total Order, WNUTO) If correct processes p and q both todeliver messages m and m', then p todelivers m before m' if and only if q todelivers m before m‘
The Order property (2)
SUTO WUTOSNUTO WNUTO
p1
p2
p3
m1
m2
m2
m1
m1
m2m4
m3
m3
m7
m6
m5
SNUTO
p1
p2
p3
m1
m2m1
m1
m2m4
m3
m3
m7
m6
m5
WNUTOm2
TO specifications
TO(UA,SUTO)The strongest TO spec.
p1
p2
p3
m2
m2
m2
m1
m1
m1
m3
m3
m4
m4
p1
p2
p3
m2
m2
m2
m1
m1
m1m4
m3
m3
m6
m6
m5
TO(NUA,SUTO) TO(UA,SUTO)(Strongest total order)
TO(NUA,SUTO)
TO specifications (2)
TO(UA,WUTO)
m3
p1
p2
p3
m2
m2
m1
m1
m1
m3
m3
m4
m4
m4
m3
p1
p2
p3
m2m1
m1
m1
m3
m4
m4
m2m3 m4
m5
m6
m6
m6
m2
m2
TO(NUA,WUTO)
TO(UA,WUTO)
TO(UA,SUTO)(Strongest total order)
TO(NUA,SUTO)
TO(NUA,WUTO)
TO specifications (3)
TO(UA,WNUTO)
m4
p1
p2
p3
m2
m2
m1
m1
m1
m3
m3
m3
m4
m4
m2
TO(NUA,WNUTO)
m4
p1
p2
p3
m2m1
m1
m1
m3
m3
m4
m2m3 m4
m5
m6
m6
m6m2 TO(NUA,WNUTO)
TO(UA,WNUTO)
TO(UA,SUTO)(Strongest total order)
TO(NUA,SUTO)TO(UA,WUTO)
TO(NUA,WUTO)
Top Related