Randomized Algorithm: Lazy Probabilistic Broadcast

The “Eager Probabilistic Broadcast” algorithm described earlier uses only gossiping to disseminate messages, where infected processes push messages to other pro-cesses. A major disadvantage of this approach is that it consumes considerable resources and causes many redundant transmissions, in order to achieve reliable delivery with high probability. A way to overcome this limitation is to rely on epi-demic push-style broadcast only in a first phase, until many processes are infected,

Algorithm 3.10: Lazy Probabilistic Broadcast (part 1, data dissemination) Implements:

ProbabilisticBroadcast, instance pb.

Uses:

FairLossPointToPointLinks, instance fll;

ProbabilisticBroadcast, instance upb. // an unreliable implementation upon event_⟨pb,Init_⟩do

next:=[1]^N; lsn:=0;

pending:=_∅; stored :=_∅; procedure gossip(msg)is

forallt∈picktargets(k)do trigger_⟨fll,Send| t,msg_⟩; upon event_⟨pb,Broadcast _{| m ⟩}do

lsn:= lsn+ 1;

trigger_⟨upb,Broadcast | [DATA, self, m,lsn]⟩; upon event_⟨upb,Deliver_{| p},[DATA,s, m, sn]⟩do

if random([0, 1]) > αthen

stored:= stored_{∪ {[}DATA,s, m, sn]}; ifsn =next[s]then

next[s]:= next[s] + 1; trigger_⟨pb,Deliver_{| s},m⟩; else ifsn >next[s]then

pending:= pending_{∪ {[}DATA,_{s, m, sn]}}; forall missing_{∈ [}next[s], . . . , sn− 1]do

if nom^′exists such that[DATA,s, m^′,missing]∈pendingthen gossip([REQUEST, self, s,missing, R− 1]);

starttimer(∆, s, sn);

and to switch to a pulling mechanism in a second phase afterward. Gossiping until, say, half of the processes are infected is efficient. The pulling phase serves a backup to inform the processes that missed the message in the first phase. The second phase uses again gossip, but only to disseminate messages about which processes have missed a message in the first phase. This idea works for scenarios where every sender broadcasts multiple messages in sequence.

For describing an implementation of this idea in a compact way, we assume here that the first phase is realized by an unreliable probabilistic broadcast abstraction, as defined by Module3.7, with a large probability ε that reliable delivery fails, in its probabilistic validityproperty. Concretely, we expect that a constant fraction of the processes, say, half of them, obtains the message after the first phase. The primitive could typically be implemented on top of fair-loss links (as the “Eager Probabilistic Broadcast” algorithm) and should work efficiently, that is, not cause an excessive amount of redundant message transmissions.

Algorithm3.10–3.11, called “Lazy Probabilistic Broadcast,” realizes probabilis-tic broadcast in two phases, with push-style gossiping followed by pulling. The

Algorithm 3.11: Lazy Probabilistic Broadcast (part 2, recovery) upon event_⟨fll,Deliver| p,[REQUEST,q, s, sn, r]⟩do

if existsmsuch that[DATA,s, m, sn]∈storedthen trigger_⟨fll,Send _{| q},[DATA,s, m, sn]⟩; else ifr > 0then

gossip([REQUEST,q, s, sn, r− 1]); upon event_⟨fll,Deliver_{| p},[DATA,s, m, sn]⟩do

pending:= pending_{∪ {[}DATA,s, m, sn]};

upon exists[DATA,s, x, sn]∈pendingsuch thatsn =next[s]do next[s]:= next[s] + 1;

pending:= pending_{\ {[}DATA,s, x, sn]}; trigger_⟨pb,Deliver_{| s},x⟩;

upon event⟨Timeout| s, sn ⟩do ifsn >next[s]then

next[s]:=sn + 1;

algorithm assumes that each sender is transmitting a stream of numbered messages.

Message omissions are detected based on gaps in the sequence numbers of received messages. Each message is disseminated using an instance upb of unreliable prob-abilistic broadcast. Each message that is retained by a randomly selected set of receivers for future retransmission. More precisely, every process that upb-delivers a message stores a copy of the message with probability α during some maximum amount of time. The purpose of this approach is to distribute the load of storing messages for future retransmission among all processes.

Omissions can be detected using sequence numbers associated with messages.

The array variable next contains an entry for every process p with the sequence num-ber of the next message to be pb-delivered from sender p. The process detects that it has missed one or more messages from p when the process receives a message from p with a larger sequence number than what it expects according to next[p]. When a process detects an omission, it uses the gossip algorithm to disseminate a retrans-mission request. If the request is received by one of the processes that has stored a copy of the message then this process retransmits the message. Note that, in this case, the gossip algorithm does not have to ensure that the retransmission request reaches all processes with high probability: it is enough that the request reaches, with high probability, one of the processes that has stored a copy of the missing message. With small probability, recovery will fail. In this case, after a timeout with delay ∆ has expired, a process simply jumps ahead and skips the missed messages, such that subsequent messages from the same sender can be delivered.

The pseudo code of Algorithm3.10–3.11uses again the functionpicktargets(k) from the previous section. The functionrandom([0, 1]) used by the algorithm returns a random real number from the interval[0, 1]. The algorithm may invoke multiple timers, where operationstarttimer(∆, parameters) starts a timer instance identified by parameters with delay ∆.

Garbage collection of the stored message copies is omitted in the pseudo code for simplicity. Note also that when a timeout for some sender s and sequence number sn occurs, the pseudo code may skip some messages with sender s in pending that have arrived meanwhile (be it through retransmissions or delayed messages from s) and that should be processed; a more complete implementation would deliver these messages and remove them from pending.

Correctness. The no creation and no duplication properties follow from the under-lying point-to-point links and the use of sequence numbers.

The probability of delivering a message to all correct processes depends here on the fanout (as in the “Eager Probabilistic Broadcast” algorithm) and on the reliabil-ity of the underlying dissemination primitive. For instance, if half of the processes upb-deliver a particular message and all of them were to store it (by setting α = 0) then the first retransmission request to reach one of these processes will be suc-cessful, and the message will be retransmitted. This means that the probability of successful retransmission behaves like the probability of successful delivery in the

“Eager Probabilistic Broadcast” algorithm.

Performance. Assuming an efficient underlying dissemination primitive, the broad-casting of a message is clearly much more efficient than in the “Eager Probabilistic Broadcast” algorithm.

It is expected that, in most cases, the retransmission request message is much smaller that the original data message. Therefore, this algorithm is also much more resource-effective than the “Eager Probabilistic Broadcast” algorithm.

Practical algorithms based on this principle make a significant effort to optimize the number of processes that store copies of each broadcast message. Not surpris-ingly, the best results can be obtained if the physical network topology is taken into account: for instance, in a wide-area system with processes in multiple LANs, an omission in a link connecting a LAN with the rest of the system affects all pro-cesses in that LAN. Thus, it is desirable to have a copy of the message in each LAN (to recover from local omissions) and a copy outside the LAN (to recover from the omission in the link to the LAN). Similarly, the retransmission procedure, instead of being completely random, may search first for a copy in the local LAN and only afterward at more distant processes.