N ETWORK E MBEDDED S YSTEMS Relia eliable ble Broadc oadcas ast t (et (et al.) al.) Hoa Do
O VERVIEW 19.04.2007 Motivation and Definition Best Effort Broadcast Regular Reliable Broadcast Lazy Reliable Broadcast Eager Reliable Broadcast 2 / 28
M OTIVATION 19.04.2007 Client-Server Computing Point-to point communication protocols Extremely useful is protocol is reliable 3 / 28
D EFINITION 19.04.2007 Reliability in context of broadcast means, that “Message exchanged between two ore more processors are not lost or duplicated , and are delivered in the order in which they were sent.” 4 / 28
D EFINITION 19.04.2007 Broadcast “The sending of one transmission to multiple users in a defined group” Best-effort : delivery among all correct processes if sender does not fail Regular Reliable : all-or-nothing delivery semantics, even if sender fails Uniform Reliable : set of message delivered by fault processes is always a subset of messages delivered by correct processes Totally ordered : delivery message follows the same global order Termination : processes either deliver a message or eventually are aware that they should never deliver the message. 5 / 28
D EFINITION 19.04.2007 Multicast “Multicast is a subset of broadcast that extends the broadcast concept of one to many by allowing "the sending of one transmission to many users in a defined group, but not necessarily to all users in that group." 6 / 28
B EST E FFORT B ROADCAST 19.04.2007 Weak form of reliability Process sends a message to all processes (including itself) One-shot operation Reliability is in charge of sender Remaining processes do not have to be concerned with enforcing the reliability of received messages No delivery guarantees if sender fails Uses perfect links 7 / 28
B EST E FFORT B ROADCAST 19.04.2007 Implementation of BestEffortBroadcast (beb): Events: Request: < bebBroadcast | m >: Used to broadcast message m to all processes Indication < bebDeliver| src, m >: Used to deliver message m broadcast by process src Uses: 8 / PerfectPointToPointLinks (pp2p) 28
B EST E FFORT B ROADCAST 19.04.2007 Pseudo Code Implementation: upon event < bebBroadcast | m > do forall p i ∏ do trigger < pp2pSend | p i ,m >; upon event < pp2pDeliver | p i ,m > do trigger < bebDeliver| p i , m >: 9 / 28
B EST E FFORT B ROADCAST 19.04.2007 10 / 28
B EST E FFORT B ROADCAST PROPERTIES 19.04.2007 BEB1 . Validity : If p i and p j are correct, then every message broadcast by p i is eventually delivered by p j BEB2 . No duplication: No message is delivered more than once BEB3 . No creation: No message is delivered unless it was broadcast 11 / 28
B EST E FFORT B ROADCAST 19.04.2007 Proofs: Correctness: derived from the properties of the underlying perfect point-to- point links ( PL1: Reliable delivery ) Validity derived from PL1 and the fact that the sender sends the message to every other process in the system No Duplication derived from PL2: No duplication No Creation derived from PL3: No creation 12 / 28
B EST E FFORT B ROADCAST 19.04.2007 Performance : Requires a single communication step Exchange of N messages (where N is the nummer of processes) 13 / 28
R EGULAR R ELIABLE B ROADCAST 19.04.2007 Stronger form of reliability Agreement is ensured even if sender fails Correct processes agree on the set of messages they deliver, even when the senders of the message crash during the transmission Sender may fail before being able to transmit the message → no process will deliver it Uses perfect links Uses perfect failure detector (optional) 14 / 28
R EGULAR R ELIABLE B ROADCAST 19.04.2007 Implementation of (regular) ReliableBroadcast (rb) Events: Request: < rbBroadcast | m >: Used to broadcast message m Indication < rbDeliver| src, m >: Used to deliver message m broadcast by process src Uses BestEffortBroadcast (beb) (only Lazy Reliable Broadcast: PerfectFailureDetector ) 15 / 28
R EGULAR R ELIABLE B ROADCAST 19.04.2007 2 Implementations: Lazy Reliable Broadcast Eager Reliable Broadcast 16 / 28
L AZY R ELIABLE B ROADCAST 19.04.2007 Uses Best Effort Broadcast to disseminate message Adds some protocol headers to the message exchanged If sender does not crash, message will be delivered to all correct processes. If sender crashes, other process can detect that crash and relays the message to all Relays only a copy of the message and not the message itself 17 / 28
L AZY R ELIABLE B ROADCAST 19.04.2007 Algorithm is said to be lazy in the sense that it retransmits a message only if the original sender has been detected to have crashed Two kinds of events can force a process to retransmit a message: Process detects the crash of the source Process delivers a message and realizes that the source has already been detected to have crashed 18 / 28
L AZY R ELIABLE B ROADCAST 19.04.2007 Implementation of (Lazy) ReliableBroadcast (rb): upon event < Init > do : delivered := Ø; correct := ∏; forall p i ∏ do from [p i ] := Ø; upon event < rbBroadcast | m > do trigger < bebBroadcast | [DATA, self, m] >; upon event < bebDeliver | p i , [DATA, s m , m] > do if ( m deliver ) then deliver := deliver {m}; trigger < rbDeliver | s m ,m >; from [p i ] := from [p i ] {(s m ,m )}; if (p i correct) then trigger < bebBroadcast | [DATA, s m , m] >; upon event <crash | p i > do correct := correct \ {p i }; 19 / forall (s m ,m) from [p i ] do 28 trigger <bebBroadcast | [DATA, s m , m] >;
L AZY RELIABLE B ROADCAST PROPERTIES 19.04.2007 RB1 = BEB1 . Validity : If p i and p j are correct, then every message broadcast by p i is eventually delivered by p j RB2 = BEB2 . No duplication: No message is delivered more than once RB3 = BEB3 . No creation: No message is delivered unless it was broadcast RB4 . Agreement : For any message m, if a correct process delivers m, then every correct process delivers m 20 / 28
L AZY R ELIABLE B ROADCAST 19.04.2007 Performance : If sender does not crash, the algorithm requires a single communication step and N messages Otherwise N 2 messages and in the worst case (process crashes in sequence) N steps are required 21 / 28
E AGER R ELIABLE B ROADCAST 19.04.2007 If accuracy property of the failure detector is not satisfied, process might be relaying messages when it is not really necessary → Waste of resource but does not impact correctness If completeness property of the failure detector is not satisfied, process might not be relaying messages that they should be relaying → Might violate agreement Circumvent the need of a failure detector by adopting an eager scheme 22 / 28
E AGER R ELIABLE B ROADCAST 19.04.2007 Every process that gets a message relays it immediately We consider the worst case → sender might have crashed → we relay every message This relaying phase is exactly what guarantees the agreement property of reliable broadcast. The resulting algorithm is called Eager Reliable Broadcast. Algorithm assumes fail silent model and does not 23 / 28 use any failure detector.
E AGER R ELIABLE B ROADCAST 19.04.2007 Implementation of (Eager) ReliableBroadcast (rb): upon event < Init > do: delivered := Ø; upon event < rbBroadcast | m > do deliver := deliver {m}; trigger < rbDeliver | self, m >; trigger <bebBroadcast | [DATA, self, m] >; upon event < bebDeliver | p i , [DATA, self, m] > do if m deliver do deliver := deliver {m}; trigger <rbDeliver | s m , m] >; trigger < bebBroadcast | [DATA, s m , m] >; 24 / 28
E AGER R ELIABLE B ROADCAST P ROPERTIES 19.04.2007 RB1 = BEB1 . RB2 = BEB2 . RB3 = BEB3 . RB4: Agreement : For any message m, if a correct process delivers m, then every correct process delivers m 25 / 28
E AGER R ELIABLE B ROADCAST P ROPERTIES 19.04.2007 Performance : In best case algorithm requires a single communication step and N 2 messages In worst case (process crashes in sequence) N steps and N 2 messages are required 26 / 28
C OMPARISON 19.04.2007 Best Effort Broadcast Regular Reliable Broadcast Reliability in charge if All-or-nothing semantic sender Agreement is ensured only ensures delivery even if the sender fails among all correct Uses perfect failure processors detector Uses perfect links 27 / 28
T HE E ND 19.04.2007 Thank you for your attention! Questions? 28 / 28
Recommend
More recommend
