Download
1 / 11
110 likes | 306 Views
Lamport (cont.): A Lossy Queue. Exactly like a regular one, but with one more allowed change: queue = Q --> queue’ < Q (could have written queue’ < queue) < means “ is a subsequence of” Problem: the liveness property of GET [] ( (in (GET) / |queue| > 0 => <> after(GET))
E N D
Lamport (cont.): A Lossy Queue • Exactly like a regular one, but with one more allowed change: queue = Q --> queue’ < Q (could have written queue’ < queue) < means “ is a subsequence of” • Problem: the liveness property of GET [] ( (in (GET) /\ |queue| > 0 => <> after(GET)) is now too strong (can’t really implement)
A Compromise • No liveness constraint on GET leads to a useless lossy queue. • Always finishing if there is an element is too demanding. • Suggested compromise: [](in(GET)/\ [] <> |queue| > 0 => <>after(GET)) • If the queue repeatedly is nonempty, eventually the GET will finish.
A Channel is a Lossy Queue • Replace PUT by TMT (transmit) • Replace GET by RCV (receive) • The TMT protocol will be in one computer and the RCV in another, with the new allowed transition modeling the possible fault of losing a message in transmission.
A Key Property • In a lossy queue, if we keep transmitting the same message, it will get through! [](( [] <> in(TMT) /\ []( at(TMT) => TMT.PAR = msg) /\ [] <> in(RCV)) => after (RCV) /\ RCV.PAR = msg ) • Can’t be stuck in RCV, because then the queue must be empty, contradicting the liveness of TMT. Thus exit RCV repeatedly, and each time remove an element. Must get to msg eventually.....
Implementing Fault Tolerance • A reliable channel: specified by original queue with SEND for PUT and RECEIVE for GET • Problem: Implement a reliable channel by imposing a Communication Protocol on two lossy queues. • Example here: alternating bit protocol • Sender module has SEND routine activated by user, and uses MTMT and ARCV. Receive module has RECEIVE routine, uses MRCV and ATMT.
המערכת השלמה ערוץ שידור אמין (בעצם ממש תור רגיל) rrcvval stmtarg snum rnum rval sarg squeue rqueue rtmtarg srcvval
Hints to Understanding • squeue has the values SENT that have not yet been moved across the lossy channel. • rqueue has the values received after crossing the lossy channel, before RECEIVE operations remove them. snum has the bit value currently being sent rnum has the bit value currently being received on the other side.
Hints (continued) • Keep sending the same (bit, value) pair until you get back an ACK with that bit, then switch your bit and start sending the new bit with the next value. • When you get a pair with a new bit put the value in the local rqueue, switch your bit and send an ACK back. Ignore additional copies with the same bit you have, but send back more ACKs with your bit. • Initially, the bits are different on each side.
The Mapping • Key to understanding: queue == if snum =/= rnum then rqueue ^ squeue else rqueue ^ tail (squeue) • The mapping changes whenever snum or rnum changes-- but the RESULT of the mapping will stay the same! (check cases where that happens) • SEND and RECEIVE change the queue
Liveness of the queue • Need to show that SEND and RECEIVE satisfy the usual queue liveness properties • Therefore, need that elements move across the lossy queue, so squeue has room, and rqueue can provide elements when queue has room/ isn’t empty (resp.) • Use reasoning by contradiction on the temporal properties.
Summary • Can model faults as ‘possible changes’ • Temporal logic gives global liveness properties not expressed in other ways. • Reasoning can be confusing, need care in choosing temporal assertions. • Open systems are especially hard to specify and verify, so tools are needed.
