Le comunicazioni ordinate. Comunicazioni Ordinate E importante (e utile) definire delle primitive di comunicazione che diano qualche garanzia sullordine.

Presentazione sul tema: "Le comunicazioni ordinate. Comunicazioni Ordinate E importante (e utile) definire delle primitive di comunicazione che diano qualche garanzia sullordine."— Transcript della presentazione:

1 Le comunicazioni ordinate

2 Comunicazioni Ordinate E importante (e utile) definire delle primitive di comunicazione che diano qualche garanzia sullordine di consegna dei messaggi inviati allinterno di un gruppo di processi Vedremo le seguenti: Comunicazione che rispetta lordine FIFO di invio dei messaggi Comunicazione che rispetta lordine causale Comunicazione che rispetta un ordine totale

3 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, (dora in poi solo Reliable broadcast) : Safety Safety. 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 Liveness Liveness: 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.

4 Utilità della comunicazione ordinata Nel Reliable broadcast non cè alcun requisito sullordine in cui i messaggi sono consegnati Per alcune applicazioni ciò può portare ad anomalie... Esempio: sistema di prenotazione aerea. Lanomalia consiste in una consegna di un msg di cancellazione di una prenotazione che il server non ha ancora registrato! t client server reservecancel Prices 15% off

5 FIFO Broadcast\specifica Qual è 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 Safety La specifica del FIFO broadcast è costituita dalle proprietà viste per il Reliable broadcast alle quali si aggiunge unaltra proprietà di Safety 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

6 Each process q holds: S p a count of messages broadcast by p R p 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 = R p + 1. If so, q FO-delivers it if S > R p + 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) FIFO Broadcast\algoritmo

7 Utilità della comunicazione ordinata(2) Il FIFO order non preclude tutte le anomalie dovute ad uno strano ordine di consegna… Es: Applicazione di tipo newsgroup. Anche se il FIFO order è soddisfatto (banalmente), cosa non va? m2 dipende da m1 ma Student 2 consegna m2 prima di m1 Qual è la soluzione? Poiché m1 precede causalmente m2, allora m2 non deve essere consegnato finchè prima non viene consegnato m1 A questo scopo introduciamo una nuova primitiva alle comunicazioni di gruppo in grado di implementare questa soluzione: Causal Broadcast Prof. Student 2 m 1 : Fri exam cancelled Student 1 m 2 : lets party on Thu night m 3 : but we have an exam on Fri!

8 Causal Order FIFO Order, ma FIFO Order Causal Order Quindi, Causal Order = FIFO Order + ? Causal Broadcast\specifica Safety La specifica del Causal broadcast è costituita dalle proprietà viste per il Reliable broadcast alle quali si aggiunge unaltra proprietà di Safety 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

9 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 t m m Viene ritardato e consegnato solo dopo la consegna di m

10 Causal Broadcast\ implementazioni Due implementazioni Un algoritmo blocking che usa vector clocks Un algoritmo non-blocking che usa il passato p1p1 p2p2 p3p3 COBcast(m 1 ) CObcast(m 2 ) COBcast(m 3 ) m 1 m 2 m 1,m 2, m 3 COdelv(m 1 ) COdelv(m 3 ) m 2 già COdelivered! COdelv(m 1 ) COdelv(m 2 ) COdelv(m 3 ) COdelv(m 2 ) scarta IDEA DI BASE: PIGGYBACKING DEI MESSAGGI che fanno parte del PASSATO del msg inviato

11 Utilità della comunicazione ordinata(3) Anche il Causal Order non è abbastanza forte per assicurare lassenza di anomalie Es. Applicazione banking. Conto bancario replicato su due siti R1R1 R2R2 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

12 Atomic Broadcast\specifica Safety La specifica del Total Order broadcast è costituita dalle proprietà viste per il Reliable broadcast alle quali si aggiunge unaltra proprietà di Safety 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.

13 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 FIFO Order Local Order Causal Order Local Order

14 Atomic Broadcast e Consenso Si può realizzare il Consenso con latomic broadcast Si può realizzare latomic 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 lAtomic Broadcast e il Consenso sono problemi equivalenti in un sistema con canali affidabili Ciò significa che non esiste alcun algoritmo che soddisfa la specifica dellatomic broadcast in un modello di sistema asincrono con guasti di tipo crash: FLP per ATOMIC BROADCAST!!

15 System model Static set of processes Π = {p 1 … p n } Message passing over perfect channels (message exchanging between correct processes is reliable) Asynchronous Crash fault model for processes We characterize the system in terms of its possible runs R R p1p1 p2p2 pnpn TOcast(m) m m m TOdeliver(m) crash r

16 A few notation Property P: predicate on the system, identifying a set of runs R P R P P iff R P R P Specification S(P 1,…,P m ): logical and of m properties, identifying a set of runs R S =R P 1 … R P m R S S iff R S R S RPRP RPRP RSRS RSRS R P1 R Pn RSRS R R R

17 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.

18 TO specifications Total Order Broadcast = S(V,I,A,O) V = Validity I = Integrity A = Agreement O = Order Distinct specifications arise from distinct formulations of each property uniform vs non-uniform A uniform property imposes restrictions on the behavior of (at least) correct processes on the basis of events occurred in some process NUV UI TO(A,O)

19 TO Specifications Crash failure + Perfect channels NUV. if a correct process TOCAST a message m then some correct process will eventually deliver m UI. 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.

20 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

21 The Agreement property Constrains the set of delivered messages Correct processes always deliver the same set of messages M Each faulty process p delivers a set M p UA: M p M NUA: M p can be s.t. M p - M m2m2 m4m4 p1p1 p2p2 p3p3 m2m2 m4m4 m1m1 m1m1 m3m3 m3m3 m3m3 m4m4 m1m1 m2m2 UA m4m4 p1p1 p2p2 p3p3 m2m2 m4m4 m1m1 m1m1 m3m3 m3m3 m3m3 m4m4 m1m1 m2m2 m5m5 NUA

22 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 order same prefix of the set of delivered messages after 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 p1p1 p2p2 p3p3 m2m2 m2m2 m2m2 m1m1 m1m1 m1m1 m4m4 m3m3 m3m3 m7m7 m6m6 m5m5 p1p1 p2p2 p3p3 m2m2 m2m2 m1m1 m1m1 m1m1 m4m4 m3m3 m3m3 m7m7 m6m6 m5m5 SUTO WUTO

23 The Order property (2) SUTO and WUTO are uniform They 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

24 The Order property (2) SUTO WUTO SNUTO WNUTO p1p1 p2p2 p3p3 m1m1 m2m2 m2m2 m1m1 m1m1 m2m2 m4m4 m3m3 m3m3 m7m7 m6m6 m5m5 SNUTO p1p1 p2p2 p3p3 m1m1 m2m2 m1m1 m1m1 m2m2 m4m4 m3m3 m3m3 m7m7 m6m6 m5m5 WNUTO m2m2

25 TO specifications TO(UA,SUTO) The strongest TO spec. p1p1 p2p2 p3p3 m2m2 m2m2 m2m2 m1m1 m1m1 m1m1 m3m3 m3m3 m4m4 m4m4 p1p1 p2p2 p3p3 m2m2 m2m2 m2m2 m1m1 m1m1 m1m1 m4m4 m3m3 m3m3 m6m6 m6m6 m5m5 TO(NUA,SUTO) TO(UA,SUTO) (Strongest total order) TO(NUA,SUTO)

26 TO specifications (2) TO(UA,WUTO) m3m3 p1p1 p2p2 p3p3 m2m2 m2m2 m1m1 m1m1 m1m1 m3m3 m3m3 m4m4 m4m4 m4m4 m3m3 p1p1 p2p2 p3p3 m2m2 m1m1 m1m1 m1m1 m3m3 m4m4 m4m4 m2m2 m3m3 m4m4 m5m5 m6m6 m6m6 m6m6 m2m2 m2m2 TO(NUA,WUTO) TO(UA,WUTO) TO(UA,SUTO) (Strongest total order) TO(NUA,SUTO) TO(NUA,WUTO)

27 TO specifications (3) TO(UA,WNUTO) m4m4 p1p1 p2p2 p3p3 m2m2 m2m2 m1m1 m1m1 m1m1 m3m3 m3m3 m3m3 m4m4 m4m4 m2m2 TO(NUA,WNUTO) m4m4 p1p1 p2p2 p3p3 m2m2 m1m1 m1m1 m1m1 m3m3 m3m3 m4m4 m2m2 m3m3 m4m4 m5m5 m6m6 m6m6 m6m6 m2m2 TO(UA,WNUTO) TO(UA,SUTO) (Strongest total order) TO(NUA,SUTO) TO(UA,WUTO) TO(NUA,WUTO)

28