the alternating bit protocol - microsoft azure · h “mary ”;1i h derf 0i “mary ”; 1i...

282
TLA + Video Course – Lecture 9, Part 2 Leslie Lamport THE ALTERNATING BIT PROTOCOL THE PROTOCOL This video should be viewed in conjunction with a Web page. To find that page, search the Web for TLA+ Video Course . The TLA + Video Course Lecture 9 The Alternating Bit Protocol

Upload: others

Post on 29-Sep-2020

2 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

TLA+ Video Course – Lecture 9, Part 2Leslie Lamport

THE ALTERNATING BIT PROTOCOL

THE PROTOCOL

This video should be viewed in conjunction with a Web page.To find that page, search the Web for TLA+ Video Course .

The TLA+ Video CourseLecture 9The Alternating Bit Protocol

Page 2: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

In this part, we examine the Alternating Bit Protocol itself, and how itimplements the liveness property of its high-level specification.

In the process, we learn about strong fairness and some more about usingthe TLC model checker.

[ slide 2 ]

Page 3: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

THE SAFETY SPECIFICATION

[ slide 3 ]

Page 4: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

What the Protocol Accomplishes

Remember what the AB protocol is supposed to accomplish.

It starts with AVar and BVar having values like these, where the firstcomponent is an arbitrary data item.

A sends a data item by setting the first element of AVar to that item andcomplementing the one-bit second element.

[ slide 4 ]

Page 5: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

What the Protocol Accomplishes

AVar :

A

〈“ ”, 1〉 BVar :

B

〈“ ”, 1〉

A Sends: “Fred ”, “Mary”, “Mary”, . . .

B Receives: “Fred ”, “Mary”, “Mary”, . . .

Remember what the AB protocol is supposed to accomplish.

It starts with AVar and BVar having values like these, where the firstcomponent is an arbitrary data item.

A sends a data item by setting the first element of AVar to that item andcomplementing the one-bit second element.

[ slide 5 ]

Page 6: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

What the Protocol Accomplishes

AVar :

A

〈“Fred ”, 0〉 BVar :

B

〈“ ”, 1〉

A Sends: “Fred ”, “Mary”, “Mary”, . . .

B Receives: “Fred ”, “Mary”, “Mary”, . . .

Remember what the AB protocol is supposed to accomplish.

It starts with AVar and BVar having values like these, where the firstcomponent is an arbitrary data item.

A sends a data item by setting the first element of AVar to that item andcomplementing the one-bit second element.

[ slide 6 ]

Page 7: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

What the Protocol Accomplishes

AVar :

A

〈“Fred ”, 0〉 BVar :

B

〈“Fred ”, 0〉

A Sends: “Fred ”, “Mary”, “Mary”, . . .

B Receives: “Fred ”, “Mary”, “Mary”, . . .

B receives that item.

A sends the next data item.

And so on.

[ slide 7 ]

Page 8: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

What the Protocol Accomplishes

AVar :

A

〈“Mary”, 1〉 BVar :

B

〈“Fred ”, 0〉

A Sends: “Fred ”, “Mary”, “Mary”, . . .

B Receives: “Fred ”, “Mary”, “Mary”, . . .

B receives that item.

A sends the next data item.

And so on.

[ slide 8 ]

Page 9: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

What the Protocol Accomplishes

AVar :

A

〈“Mary”, 1〉 BVar :

B

〈“Mary”, 1〉

A Sends: “Fred ”, “Mary”, “Mary”, . . .

B Receives: “Fred ”, “Mary”, “Mary”, . . .

B receives that item.

A sends the next data item.

And so on.

[ slide 9 ]

Page 10: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

What the Protocol Accomplishes

AVar :

A

〈“Mary”, 0〉 BVar :

B

〈“Mary”, 1〉

A Sends: “Fred ”, “Mary”, “Mary”, . . .

B Receives: “Fred ”, “Mary”, “Mary”, . . .

B receives that item.

A sends the next data item.

And so on.

[ slide 10 ]

Page 11: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

What the Protocol Accomplishes

AVar :

A

〈“Mary”, 0〉 BVar :

B

〈“Mary”, 0〉

A Sends: “Fred ”, “Mary”, “Mary”, . . .

B Receives: “Fred ”, “Mary”, “Mary”, . . .

B receives that item.

A sends the next data item.

And so on.

[ slide 11 ]

Page 12: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

What the Protocol Accomplishes

AVar :

A

〈“Mary”, 0〉 BVar :

B

〈“Mary”, 0〉

A Sends: “Fred ”, “Mary”, “Mary”, . . .

B Receives: “Fred ”, “Mary”, “Mary”, . . .

B receives that item.

A sends the next data item.

And so on.

[ slide 12 ]

Page 13: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

Here’s how the protocol works.

A and B communicate over two channels, one from A to B and one from B

to A. The channels can lose messages.

A sends its current value to B .Since messages can be lost, A keeps sending its value

[ slide 13 ]

Page 14: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

Here’s how the protocol works.

A and B communicate over two channels, one from A to B and one from B

to A. The channels can lose messages.

A sends its current value to B .Since messages can be lost, A keeps sending its value

[ slide 14 ]

Page 15: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉

Here’s how the protocol works.

A and B communicate over two channels, one from A to B and one from B

to A. The channels can lose messages.

A sends its current value to B .Since messages can be lost, A keeps sending its value

[ slide 15 ]

Page 16: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉

Here’s how the protocol works.

A and B communicate over two channels, one from A to B and one from B

to A. The channels can lose messages.

A sends its current value to B .Since messages can be lost, A keeps sending its value

[ slide 16 ]

Page 17: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉

Here’s how the protocol works.

A and B communicate over two channels, one from A to B and one from B

to A. The channels can lose messages.

A sends its current value to B .Since messages can be lost, A keeps sending its value

[ slide 17 ]

Page 18: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉

Here’s how the protocol works.

A and B communicate over two channels, one from A to B and one from B

to A. The channels can lose messages.

A sends its current value to B .Since messages can be lost, A keeps sending its value

[ slide 18 ]

Page 19: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

Here’s how the protocol works.

A and B communicate over two channels, one from A to B and one from B

to A. The channels can lose messages.

A sends its current value to B .Since messages can be lost, A keeps sending its value

[ slide 19 ]

Page 20: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

Here’s how the protocol works.

A and B communicate over two channels, one from A to B and one from B

to A. The channels can lose messages.

A sends its current value to B .Since messages can be lost, A keeps sending its value

[ slide 20 ]

Page 21: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

0

Meanwhile, B acknowledges the last value it received by sending its bit.

And because the message might get lost,B keeps sending it.

When B receives the next message on the channel A to B , it knows that thisis a new value because the message’s bit is different from its bit.

[ slide 21 ]

Page 22: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

0

Meanwhile, B acknowledges the last value it received by sending its bit.

And because the message might get lost,B keeps sending it.

When B receives the next message on the channel A to B , it knows that thisis a new value because the message’s bit is different from its bit.

[ slide 22 ]

Page 23: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

0

Meanwhile, B acknowledges the last value it received by sending its bit.

And because the message might get lost,B keeps sending it.

When B receives the next message on the channel A to B , it knows that thisis a new value because the message’s bit is different from its bit.

[ slide 23 ]

Page 24: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

Meanwhile, B acknowledges the last value it received by sending its bit.

And because the message might get lost,B keeps sending it.

When B receives the next message on the channel A to B , it knows that thisis a new value because the message’s bit is different from its bit.

[ slide 24 ]

Page 25: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

0

Meanwhile, B acknowledges the last value it received by sending its bit.

And because the message might get lost,B keeps sending it.

When B receives the next message on the channel A to B , it knows that thisis a new value because the message’s bit is different from its bit.

[ slide 25 ]

Page 26: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

0

Meanwhile, B acknowledges the last value it received by sending its bit.

And because the message might get lost,B keeps sending it.

When B receives the next message on the channel A to B , it knows that thisis a new value because the message’s bit is different from its bit.

[ slide 26 ]

Page 27: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

0

Meanwhile, B acknowledges the last value it received by sending its bit.

And because the message might get lost,B keeps sending it.

When B receives the next message on the channel A to B , it knows that thisis a new value because the message’s bit is different from its bit.

[ slide 27 ]

Page 28: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

0

Meanwhile, B acknowledges the last value it received by sending its bit.

And because the message might get lost,B keeps sending it.

When B receives the next message on the channel A to B , it knows that thisis a new value because the message’s bit is different from its bit.

[ slide 28 ]

Page 29: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

0

Meanwhile, B acknowledges the last value it received by sending its bit.

And because the message might get lost,B keeps sending it.

When B receives the next message on the channel A to B , it knows that thisis a new value because the message’s bit is different from its bit.

[ slide 29 ]

Page 30: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Fred”, 0〉

〈“Mary”, 1〉〈“Mary”, 1〉

0

Meanwhile, B acknowledges the last value it received by sending its bit.

And because the message might get lost,B keeps sending it.

When B receives the next message on the channel A to B , it knows that thisis a new value because the message’s bit is different from its bit.

[ slide 30 ]

Page 31: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉

0

So it changes BVar .

It then starts sending its new bit.

When A receives the next message on the channel B to A, it knows that thisis an acknowledgement of its previous value because the message’s bit isdifferent from its bit.

[ slide 31 ]

Page 32: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉

0 1

So it changes BVar .

It then starts sending its new bit.

When A receives the next message on the channel B to A, it knows that thisis an acknowledgement of its previous value because the message’s bit isdifferent from its bit.

[ slide 32 ]

Page 33: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉

0 1

So it changes BVar .

It then starts sending its new bit.

When A receives the next message on the channel B to A, it knows that thisis an acknowledgement of its previous value because the message’s bit isdifferent from its bit.

[ slide 33 ]

Page 34: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉

0 1

So it changes BVar .

It then starts sending its new bit.

When A receives the next message on the channel B to A, it knows that thisis an acknowledgement of its previous value because the message’s bit isdifferent from its bit.

[ slide 34 ]

Page 35: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉

0 1

So it changes BVar .

It then starts sending its new bit.

When A receives the next message on the channel B to A, it knows that thisis an acknowledgement of its previous value because the message’s bit isdifferent from its bit.

[ slide 35 ]

Page 36: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉

1

So A ignores the message and keeps sending its current value.

Similarly, when B receives its next message on channel A to B , it knows thisis a value it has already received because the message’s bit is the same asits bit.

So B ignores the message. and keeps sending its bit.

[ slide 36 ]

Page 37: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉〈“Mary”, 1〉

1

So A ignores the message and keeps sending its current value.

Similarly, when B receives its next message on channel A to B , it knows thisis a value it has already received because the message’s bit is the same asits bit.

So B ignores the message. and keeps sending its bit.

[ slide 37 ]

Page 38: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉〈“Mary”, 1〉

1

So A ignores the message and keeps sending its current value.

Similarly, when B receives its next message on channel A to B , it knows thisis a value it has already received because the message’s bit is the same asits bit.

So B ignores the message. and keeps sending its bit.

[ slide 38 ]

Page 39: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉〈“Mary”, 1〉

1

So A ignores the message and keeps sending its current value.

Similarly, when B receives its next message on channel A to B , it knows thisis a value it has already received because the message’s bit is the same asits bit.

So B ignores the message. and keeps sending its bit.

[ slide 39 ]

Page 40: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉

1

So A ignores the message and keeps sending its current value.

Similarly, when B receives its next message on channel A to B , it knows thisis a value it has already received because the message’s bit is the same asits bit.

So B ignores the message. and keeps sending its bit.

[ slide 40 ]

Page 41: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉

1 1

So A ignores the message and keeps sending its current value.

Similarly, when B receives its next message on channel A to B , it knows thisis a value it has already received because the message’s bit is the same asits bit.

So B ignores the message. and keeps sending its bit.

[ slide 41 ]

Page 42: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉

1 1

So A ignores the message and keeps sending its current value.

Similarly, when B receives its next message on channel A to B , it knows thisis a value it has already received because the message’s bit is the same asits bit.

So B ignores the message. and keeps sending its bit.

[ slide 42 ]

Page 43: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉

1 1

So A ignores the message and keeps sending its current value.

Similarly, when B receives its next message on channel A to B , it knows thisis a value it has already received because the message’s bit is the same asits bit.

So B ignores the message. and keeps sending its bit.

[ slide 43 ]

Page 44: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Mary”, 1〉 〈“Mary”, 1〉

〈“Mary”, 1〉

1 1

When A receives the next message on the channel B to A, it knows that thisis an acknowledgement of its current value because the message’s bit is thesame as its bit.

So A chooses a new data item and flips its bit.

And so on.[ slide 44 ]

Page 45: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Anne”, 0〉 〈“Mary”, 1〉

〈“Mary”, 1〉

1

When A receives the next message on the channel B to A, it knows that thisis an acknowledgement of its current value because the message’s bit is thesame as its bit.

So A chooses a new data item and flips its bit.

And so on.[ slide 45 ]

Page 46: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Anne”, 0〉 〈“Mary”, 1〉

〈“Mary”, 1〉〈“Anne”, 0〉

1

When A receives the next message on the channel B to A, it knows that thisis an acknowledgement of its current value because the message’s bit is thesame as its bit.

So A chooses a new data item and flips its bit.

And so on.[ slide 46 ]

Page 47: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Anne”, 0〉 〈“Mary”, 1〉

〈“Mary”, 1〉〈“Anne”, 0〉

1

When A receives the next message on the channel B to A, it knows that thisis an acknowledgement of its current value because the message’s bit is thesame as its bit.

So A chooses a new data item and flips its bit.

And so on.[ slide 47 ]

Page 48: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Anne”, 0〉 〈“Mary”, 1〉

〈“Mary”, 1〉〈“Anne”, 0〉

1 1

When A receives the next message on the channel B to A, it knows that thisis an acknowledgement of its current value because the message’s bit is thesame as its bit.

So A chooses a new data item and flips its bit.

And so on.[ slide 48 ]

Page 49: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How the Protocol Works

A B

AVar : BVar :

-AtoB

� BtoA

〈“Anne”, 0〉 〈“Mary”, 1〉

〈“Mary”, 1〉〈“Anne”, 0〉

1 1

When A receives the next message on the channel B to A, it knows that thisis an acknowledgement of its current value because the message’s bit is thesame as its bit.

So A chooses a new data item and flips its bit.

And so on.[ slide 49 ]

Page 50: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The TLA+ Specification

Download module AB and open it in theToolbox.

Nothing new except the use of operationson sequences.

We now look at the safety part of the TLA+ specification.

It’s in module AB . Download that spec now and open it in the Toolbox.

There’s nothing new in the safety spec except that it uses the operations onsequences we examined in part one of this lecture.

[ slide 50 ]

Page 51: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The TLA+ Specification

Download module AB and open it in theToolbox.

Nothing new except the use of operationson sequences.

We now look at the safety part of the TLA+ specification.

It’s in module AB . Download that spec now and open it in the Toolbox.

There’s nothing new in the safety spec except that it uses the operations onsequences we examined in part one of this lecture.

[ slide 51 ]

Page 52: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The TLA+ Specification

Download module AB and open it in theToolbox.

Nothing new except the use of operationson sequences.

We now look at the safety part of the TLA+ specification.

It’s in module AB . Download that spec now and open it in the Toolbox.

There’s nothing new in the safety spec except that it uses the operations onsequences we examined in part one of this lecture.

[ slide 52 ]

Page 53: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

As usual, the module begins with an EXTENDS statement that imports theIntegers moduleand the Sequences module that defines the operators on sequences.

The constant Data is the same set of data items as in module ABSpec.

Remove of i , seek was defined in part 1 to equalsequence seq with its i th element removed.

[ slide 53 ]

Page 54: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Imports operators on sequences.

As usual, the module begins with an EXTENDS statement that imports theIntegers moduleand the Sequences module that defines the operators on sequences.

The constant Data is the same set of data items as in module ABSpec.

Remove of i , seek was defined in part 1 to equalsequence seq with its i th element removed.

[ slide 54 ]

Page 55: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

As usual, the module begins with an EXTENDS statement that imports theIntegers moduleand the Sequences module that defines the operators on sequences.

The constant Data is the same set of data items as in module ABSpec.

Remove of i , seek was defined in part 1 to equalsequence seq with its i th element removed.

[ slide 55 ]

Page 56: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Same as in ABSpec.

As usual, the module begins with an EXTENDS statement that imports theIntegers moduleand the Sequences module that defines the operators on sequences.

The constant Data is the same set of data items as in module ABSpec.

Remove of i , seek was defined in part 1 to equalsequence seq with its i th element removed.

[ slide 56 ]

Page 57: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

As usual, the module begins with an EXTENDS statement that imports theIntegers moduleand the Sequences module that defines the operators on sequences.

The constant Data is the same set of data items as in module ABSpec.

Remove of i , seek was defined in part 1 to equalsequence seq with its i th element removed.

[ slide 57 ]

Page 58: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Sequence seq with itsi th element removed.

As usual, the module begins with an EXTENDS statement that imports theIntegers moduleand the Sequences module that defines the operators on sequences.

The constant Data is the same set of data items as in module ABSpec.

Remove of i , seek was defined in part 1 to equalsequence seq with its i th element removed.

[ slide 58 ]

Page 59: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

And this is the definition we saw before.

[ slide 59 ]

Page 60: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

AVar and BVar are the same variables as in ABSpec, while A to B andB to A are additional variables that represent the message channels.

As usual, we define vars to be the tuple of all variables.

Next is the type-correctness invariant.

The possible values of AVar and BVar are the same as in ABSpec.

[ slide 60 ]

Page 61: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

AVar and BVar are the same variables as in ABSpec, while A to B andB to A are additional variables that represent the message channels.

As usual, we define vars to be the tuple of all variables.

Next is the type-correctness invariant.

The possible values of AVar and BVar are the same as in ABSpec.

[ slide 61 ]

Page 62: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

AVar and BVar are the same variables as in ABSpec, while A to B andB to A are additional variables that represent the message channels.

As usual, we define vars to be the tuple of all variables.

Next is the type-correctness invariant.

The possible values of AVar and BVar are the same as in ABSpec.

[ slide 62 ]

Page 63: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

AVar and BVar are the same variables as in ABSpec, while A to B andB to A are additional variables that represent the message channels.

As usual, we define vars to be the tuple of all variables.

Next is the type-correctness invariant.

The possible values of AVar and BVar are the same as in ABSpec.

[ slide 63 ]

Page 64: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Same as in ABSpec.

AVar and BVar are the same variables as in ABSpec, while A to B andB to A are additional variables that represent the message channels.

As usual, we define vars to be the tuple of all variables.

Next is the type-correctness invariant.

The possible values of AVar and BVar are the same as in ABSpec.

[ slide 64 ]

Page 65: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

AtoB is an element of the set of all sequences of values that A can send.

A sends a message by appending it to the end of AtoB .

B receives the message at the head of AtoB .

[ slide 65 ]

Page 66: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The set of sequences of

AtoB is an element of the set of all sequences of values that A can send.

A sends a message by appending it to the end of AtoB .

B receives the message at the head of AtoB .

[ slide 66 ]

Page 67: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The set of sequences of values A can send.

AtoB is an element of the set of all sequences of values that A can send.

A sends a message by appending it to the end of AtoB .

B receives the message at the head of AtoB .

[ slide 67 ]

Page 68: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A sends a message by appending it to the end of AtoB .B receives the message at the head of AtoB .

AtoB is an element of the set of all sequences of values that A can send.

A sends a message by appending it to the end of AtoB .

B receives the message at the head of AtoB .

[ slide 68 ]

Page 69: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A sends a message by appending it to the end of AtoB .B receives the message at the head of AtoB .

AtoB is an element of the set of all sequences of values that A can send.

A sends a message by appending it to the end of AtoB .

B receives the message at the head of AtoB .

[ slide 69 ]

Page 70: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The set of sequences of bits

And similarly, the value of BtoA is always a sequence of bits.

AVar and BVar have the same initial values as in ABSpec.

And the channels initially equal the empty sequence.[ slide 70 ]

Page 71: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Same as in ABSpec

And similarly, the value of BtoA is always a sequence of bits.

AVar and BVar have the same initial values as in ABSpec.

And the channels initially equal the empty sequence.[ slide 71 ]

Page 72: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Channels are empty.

And similarly, the value of BtoA is always a sequence of bits.

AVar and BVar have the same initial values as in ABSpec.

And the channels initially equal the empty sequence.[ slide 72 ]

Page 73: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

And similarly, the value of BtoA is always a sequence of bits.

AVar and BVar have the same initial values as in ABSpec.

And the channels initially equal the empty sequence.[ slide 73 ]

Page 74: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The subactions of Next

ASnd∆= A sends a message.

ARcv∆= A receives a message.

BSnd∆= B sends a message.

BRcv∆= B receives a message.

LoseMsg∆= A message is lost.

The next-state action is the disjunction of five subactions whose definitionscome next.

A-send is defined to be the action of A sending a message.

A-receive is defined to be the action of A receiving a message.

[ slide 74 ]

Page 75: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The subactions of Next

ASnd∆= A sends a message.

ARcv∆= A receives a message.

BSnd∆= B sends a message.

BRcv∆= B receives a message.

LoseMsg∆= A message is lost.

The next-state action is the disjunction of five subactions whose definitionscome next.

A-send is defined to be the action of A sending a message.

A-receive is defined to be the action of A receiving a message.

[ slide 75 ]

Page 76: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The subactions of Next

ASnd∆= A sends a message.

ARcv∆= A receives a message.

BSnd∆= B sends a message.

BRcv∆= B receives a message.

LoseMsg∆= A message is lost.

The next-state action is the disjunction of five subactions whose definitionscome next.

A-send is defined to be the action of A sending a message.

A-receive is defined to be the action of A receiving a message.

[ slide 76 ]

Page 77: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The subactions of Next

ASnd∆= A sends a message.

ARcv∆= A receives a message.

BSnd∆= B sends a message.

BRcv∆= B receives a message.

LoseMsg∆= A message is lost.

The next-state action is the disjunction of five subactions whose definitionscome next.

A-send is defined to be the action of A sending a message.

A-receive is defined to be the action of A receiving a message.

[ slide 77 ]

Page 78: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The subactions of Next

ASnd∆= A sends a message.

ARcv∆= A receives a message.

BSnd∆= B sends a message.

BRcv∆= B receives a message.

LoseMsg∆= A message is lost.

The next-state action is the disjunction of five subactions whose definitionscome next.

A-send is defined to be the action of A sending a message.

A-receive is defined to be the action of A receiving a message.

[ slide 78 ]

Page 79: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The subactions of Next

ASnd∆= A sends a message.

ARcv∆= A receives a message.

BSnd∆= B sends a message.

BRcv∆= B receives a message.

LoseMsg∆= A message is lost.

Similarly for B-send and B-receive.

And Lose-Message is the action that describes losing a message.

[ slide 79 ]

Page 80: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The subactions of Next

ASnd∆= A sends a message.

ARcv∆= A receives a message.

BSnd∆= B sends a message.

BRcv∆= B receives a message.

LoseMsg∆= A message is lost.

Similarly for B-send and B-receive.

And Lose-Message is the action that describes losing a message.

[ slide 80 ]

Page 81: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The subactions of Next

ASnd∆= A sends a message.

ARcv∆= A receives a message.

BSnd∆= B sends a message.

BRcv∆= B receives a message.

LoseMsg∆= A message is lost.

Similarly for B-send and B-receive.

And Lose-Message is the action that describes losing a message.

[ slide 81 ]

Page 82: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The subactions of Next

ASnd∆= A sends a message.

ARcv∆= A receives a message.

BSnd∆= B sends a message.

BRcv∆= B receives a message.

LoseMsg∆= A message is lost.

Similarly for B-send and B-receive.

And Lose-Message is the action that describes losing a message.

[ slide 82 ]

Page 83: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The subactions of Next

ASnd∆= A sends a message.

ARcv∆= A receives a message.

BSnd∆= B sends a message.

BRcv∆= B receives a message.

LoseMsg∆= A message is lost.

Similarly for B-send and B-receive.

And Lose-Message is the action that describes losing a message.

[ slide 83 ]

Page 84: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The subactions of Next

ASnd∆= A sends a message.

ARcv∆= A receives a message.

BSnd∆= B sends a message.

BRcv∆= B receives a message.

LoseMsg∆= A message is lost.

Similarly for B-send and B-receive.

And Lose-Message is the action that describes losing a message.

[ slide 84 ]

Page 85: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The definition of A-send is simple.It appends the value of AVar to the end of the sequence A-to-BAnd leaves all the other variables unchanged.

The action is always enabled.

The action of A receiving a message from B

[ slide 85 ]

Page 86: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The definition of A-send is simple.It appends the value of AVar to the end of the sequence A-to-BAnd leaves all the other variables unchanged.

The action is always enabled.

The action of A receiving a message from B

[ slide 86 ]

Page 87: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The definition of A-send is simple.It appends the value of AVar to the end of the sequence A-to-BAnd leaves all the other variables unchanged.

The action is always enabled.

The action of A receiving a message from B

[ slide 87 ]

Page 88: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The definition of A-send is simple.It appends the value of AVar to the end of the sequence A-to-BAnd leaves all the other variables unchanged.

The action is always enabled.

The action of A receiving a message from B

[ slide 88 ]

Page 89: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

is enabled only when the sequence B -to-A of messages from B is not empty.

If the bit at the head of B -to-A equals AVar ’s bit, so B is acknowledgingAVar ’s current value,then the new value of AVar is set just like in the A action of ABSpec: to a pairwhose first element is a non-deterministically chosen element of Data,[ slide 89 ]

Page 90: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

is enabled only when the sequence B -to-A of messages from B is not empty.

If the bit at the head of B -to-A equals AVar ’s bit, so B is acknowledgingAVar ’s current value,then the new value of AVar is set just like in the A action of ABSpec: to a pairwhose first element is a non-deterministically chosen element of Data,[ slide 90 ]

Page 91: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

is enabled only when the sequence B -to-A of messages from B is not empty.

If the bit at the head of B -to-A equals AVar ’s bit, so B is acknowledgingAVar ’s current value,then the new value of AVar is set just like in the A action of ABSpec: to a pairwhose first element is a non-deterministically chosen element of Data,[ slide 91 ]

Page 92: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

is enabled only when the sequence B -to-A of messages from B is not empty.

If the bit at the head of B -to-A equals AVar ’s bit, so B is acknowledgingAVar ’s current value,then the new value of AVar is set just like in the A action of ABSpec: to a pairwhose first element is a non-deterministically chosen element of Data,[ slide 92 ]

Page 93: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

and whose second element is the complement of the current value of AVar ’sbit.

Otherwise, AVar is unchanged.

And the message A is receiving, which is at the head of the sequenceB -to-A, is removed from B -to-A.

[ slide 93 ]

Page 94: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

and whose second element is the complement of the current value of AVar ’sbit.

Otherwise, AVar is unchanged.

And the message A is receiving, which is at the head of the sequenceB -to-A, is removed from B -to-A.

[ slide 94 ]

Page 95: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

and whose second element is the complement of the current value of AVar ’sbit.

Otherwise, AVar is unchanged.

And the message A is receiving, which is at the head of the sequenceB -to-A, is removed from B -to-A.

[ slide 95 ]

Page 96: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The definitions of BSnd and BRcv are similar; you can read them yourself.

[ slide 96 ]

Page 97: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Next comes the definition of Lose Message.

It removes a message from AtoB or BtoA and leaves AVar and BVar

unchanged.

The formula that describes removing a message from AtoB asserts that forsome i between 1 and the length of the sequence AtoB

[ slide 97 ]

Page 98: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Remove a message from AtoB .

Remove a message from BtoA .

Next comes the definition of Lose Message.

It removes a message from AtoB or BtoA and leaves AVar and BVar

unchanged.

The formula that describes removing a message from AtoB asserts that forsome i between 1 and the length of the sequence AtoB

[ slide 98 ]

Page 99: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Remove a message from BtoA .

Next comes the definition of Lose Message.

It removes a message from AtoB or BtoA and leaves AVar and BVar

unchanged.

The formula that describes removing a message from AtoB asserts that forsome i between 1 and the length of the sequence AtoB

[ slide 99 ]

Page 100: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Remove a message from BtoA .

the new value of AtoB is the sequence obtained by removing the i th elementfrom the current value of AtoB .

And BtoA is unchanged.

The formula that describes removing a message from BtoA

is similar.

[ slide 100 ]

Page 101: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Remove a message from BtoA .

the new value of AtoB is the sequence obtained by removing the i th elementfrom the current value of AtoB .

And BtoA is unchanged.

The formula that describes removing a message from BtoA

is similar.

[ slide 101 ]

Page 102: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Remove a message from BtoA .

the new value of AtoB is the sequence obtained by removing the i th elementfrom the current value of AtoB .

And BtoA is unchanged.

The formula that describes removing a message from BtoA

is similar.

[ slide 102 ]

Page 103: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

the new value of AtoB is the sequence obtained by removing the i th elementfrom the current value of AtoB .

And BtoA is unchanged.

The formula that describes removing a message from BtoA

is similar.

[ slide 103 ]

Page 104: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Then comes the definition of Next

and the standard safety specification.

[ slide 104 ]

Page 105: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Then comes the definition of Next

and the standard safety specification.

[ slide 105 ]

Page 106: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

CHECKING SAFETY

[ slide 106 ]

Page 107: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Create a new model with the default specification Spec,

letting Data be a small set of model values.

[ slide 107 ]

Page 108: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Create a new model with the default specification Spec,

letting Data be a small set of model values.

[ slide 108 ]

Page 109: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

But don’t run TLC yet.

Have TLC check that TypeOK is an invariant.

But don’t run it yet.

[ slide 109 ]

Page 110: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

But don’t run TLC yet.

Have TLC check that TypeOK is an invariant.

But don’t run it yet.

[ slide 110 ]

Page 111: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A and B can keep sending messages fasterthan they get lost or received.

There is no limit to how long the sequencesAtoB and BtoA can be.

There are infinitely many reachable states,so TLC will run forever.

We could change the spec to limit the lengths ofAtoB and BtoA , but we shouldn’t have to changethe specification to model check it.

A and B can keep sending messages faster than they get lost or received.

So there’s no limit to how long the sequences AtoB and BtoA can be.

The specification allows infinitely many reachable states, and since TLC triesto compute all reachable states, it will run forever.

[ slide 111 ]

Page 112: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A and B can keep sending messages fasterthan they get lost or received.

There is no limit to how long the sequencesAtoB and BtoA can be.

There are infinitely many reachable states,so TLC will run forever.

We could change the spec to limit the lengths ofAtoB and BtoA , but we shouldn’t have to changethe specification to model check it.

A and B can keep sending messages faster than they get lost or received.

So there’s no limit to how long the sequences AtoB and BtoA can be.

The specification allows infinitely many reachable states, and since TLC triesto compute all reachable states, it will run forever.

[ slide 112 ]

Page 113: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A and B can keep sending messages fasterthan they get lost or received.

There is no limit to how long the sequencesAtoB and BtoA can be.

There are infinitely many reachable states,so TLC will run forever.

We could change the spec to limit the lengths ofAtoB and BtoA , but we shouldn’t have to changethe specification to model check it.

A and B can keep sending messages faster than they get lost or received.

So there’s no limit to how long the sequences AtoB and BtoA can be.

The specification allows infinitely many reachable states, and since TLC triesto compute all reachable states, it will run forever.

[ slide 113 ]

Page 114: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A and B can keep sending messages fasterthan they get lost or received.

There is no limit to how long the sequencesAtoB and BtoA can be.

There are infinitely many reachable states,so TLC will run forever.

We could change the spec to limit the lengths ofAtoB and BtoA , but we shouldn’t have to changethe specification to model check it.

A and B can keep sending messages faster than they get lost or received.

So there’s no limit to how long the sequences AtoB and BtoA can be.

The specification allows infinitely many reachable states, and since TLC triesto compute all reachable states, it will run forever.

[ slide 114 ]

Page 115: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A and B can keep sending messages fasterthan they get lost or received.

There is no limit to how long the sequencesAtoB and BtoA can be.

There are infinitely many reachable states,so TLC will run forever.

We could change the spec to limit the lengths ofAtoB and BtoA , but we shouldn’t have to changethe specification to model check it.

We could change the spec to limit the lengths of AtoB and BtoA, but weshouldn’t have to change the spec to model check it.

[ slide 115 ]

Page 116: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A and B can keep sending messages fasterthan they get lost or received.

There is no limit to how long the sequencesAtoB and BtoA can be.

There are infinitely many reachable states,so TLC will run forever.

We could change the spec to limit the lengths ofAtoB and BtoA , but we shouldn’t have to changethe specification to model check it.

We could change the spec to limit the lengths of AtoB and BtoA, but weshouldn’t have to change the spec to model check it.

[ slide 116 ]

Page 117: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

We can tell TLC to examine only stateswhere AtoB and BtoA are not too long.

Tell TLC to examine only states withLen(AtoB) and Len(BtoA) at most 3.

Here’s how we can tell TLC to examine only states in which AtoB and BtoA

aren’t too long.

On the model’s advanced options page, go to the state constraint section.

[ slide 117 ]

Page 118: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Tell TLC to examine only states withLen(AtoB) and Len(BtoA) at most 3.

Here’s how we can tell TLC to examine only states in which AtoB and BtoA

aren’t too long.

On the model’s advanced options page, go to the state constraint section.

[ slide 118 ]

Page 119: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Tell TLC to examine only states withLen(AtoB) and Len(BtoA) at most 3.

Here’s how we can tell TLC to examine only states in which AtoB and BtoA

aren’t too long.

On the model’s advanced options page, go to the state constraint section.

[ slide 119 ]

Page 120: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Tell TLC to examine only states withLen(AtoB) and Len(BtoA) at most 3.

For example, you can tell TLC to examine only states in which the lengths ofAtoB and BtoA are at most 3,by entering this state formula.

To understand exactly what this does

[ slide 120 ]

Page 121: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Tell TLC to examine only states withLen(AtoB) and Len(BtoA) at most 3.

For example, you can tell TLC to examine only states in which the lengths ofAtoB and BtoA are at most 3,by entering this state formula.

To understand exactly what this does

[ slide 121 ]

Page 122: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Tell TLC to examine only states withLen(AtoB) and Len(BtoA) at most 3.

For example, you can tell TLC to examine only states in which the lengths ofAtoB and BtoA are at most 3,by entering this state formula.

To understand exactly what this does

[ slide 122 ]

Page 123: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Computes Reachable States

you need to understand how TLC computes reachable states when it has nostate constraint.

Starting from the set of initial states. It chooses one. and computes allpossible next states from that state.

And so on, until it has explored all reachable states.

[ slide 123 ]

Page 124: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Computes Reachable States

i i

you need to understand how TLC computes reachable states when it has nostate constraint.

Starting from the set of initial states. It chooses one. and computes allpossible next states from that state.

And so on, until it has explored all reachable states.

[ slide 124 ]

Page 125: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Computes Reachable States

i ir

you need to understand how TLC computes reachable states when it has nostate constraint.

Starting from the set of initial states. It chooses one. and computes allpossible next states from that state.

And so on, until it has explored all reachable states.

[ slide 125 ]

Page 126: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Computes Reachable States

i iri i

iiK�

R�

you need to understand how TLC computes reachable states when it has nostate constraint.

Starting from the set of initial states. It chooses one. and computes allpossible next states from that state.

And so on, until it has explored all reachable states.

[ slide 126 ]

Page 127: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Computes Reachable States

ir ii i

iiK�

R�

It then chooses another state to explore. and finds all possible next statesfrom it.

It then chooses another unexplored state and finds its next states.

And it keeps on doing this.

And so on, until it has explored all reachable states.

[ slide 127 ]

Page 128: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Computes Reachable States

ir ii i

iiii �

IK�

R�

It then chooses another state to explore. and finds all possible next statesfrom it.

It then chooses another unexplored state and finds its next states.

And it keeps on doing this.

And so on, until it has explored all reachable states.

[ slide 128 ]

Page 129: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Computes Reachable States

i iir i

iiii �

IK�

R�

It then chooses another state to explore. and finds all possible next statesfrom it.

It then chooses another unexplored state and finds its next states.

And it keeps on doing this.

And so on, until it has explored all reachable states.

[ slide 129 ]

Page 130: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Computes Reachable States

i iir i

iiiii i i i

IK�

R�

Y M � 1

It then chooses another state to explore. and finds all possible next statesfrom it.

It then chooses another unexplored state and finds its next states.

And it keeps on doing this.

And so on, until it has explored all reachable states.

[ slide 130 ]

Page 131: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Computes Reachable States

i ii ir

iiiii i i i

IK�

R�

Y M � 1

It then chooses another state to explore. and finds all possible next statesfrom it.

It then chooses another unexplored state and finds its next states.

And it keeps on doing this.

And so on, until it has explored all reachable states.

[ slide 131 ]

Page 132: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Computes Reachable States

i ii ir

iiiii i i i i

IK�

R�

Y M � 1�1

It then chooses another state to explore. and finds all possible next statesfrom it.

It then chooses another unexplored state and finds its next states.

And it keeps on doing this.

And so on, until it has explored all reachable states.

[ slide 132 ]

Page 133: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Computes Reachable States

i ii i

iriiii i i i i

IK�

R�

Y M � 1�1

It then chooses another state to explore. and finds all possible next statesfrom it.

It then chooses another unexplored state and finds its next states.

And it keeps on doing this.

And so on, until it has explored all reachable states.

[ slide 133 ]

Page 134: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Computes Reachable States

i ii i

iriiii i i i i

iii

IK�

R�

Y M � 1�1

j?

It then chooses another state to explore. and finds all possible next statesfrom it.

It then chooses another unexplored state and finds its next states.

And it keeps on doing this.

And so on, until it has explored all reachable states.

[ slide 134 ]

Page 135: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Computes Reachable States

i ii i

iiriii i i i i

iii

IK�

R�

Y M � 1�1

j?

It then chooses another state to explore. and finds all possible next statesfrom it.

It then chooses another unexplored state and finds its next states.

And it keeps on doing this.

And so on, until it has explored all reachable states.

[ slide 135 ]

Page 136: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Computes Reachable States

i ii i

iiriii i i i i

iiiii

IK�

R�

Y M � 1�1

j?

?�

1

j

1

j

It then chooses another state to explore. and finds all possible next statesfrom it.

It then chooses another unexplored state and finds its next states.

And it keeps on doing this.

And so on, until it has explored all reachable states.

[ slide 136 ]

Page 137: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Computes Reachable States

i ii i

iiirii i i i i

iiiii

IK�

R�

Y M � 1�1

j?

?�

1

j

1

j

It then chooses another state to explore. and finds all possible next statesfrom it.

It then chooses another unexplored state and finds its next states.

And it keeps on doing this.

And so on, until it has explored all reachable states.

[ slide 137 ]

Page 138: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Uses a Constraint

Now here’s how TLC computes reachable states when it has a stateconstraint.

Starting from the set of initial states. It chooses one and then checks if thestate satisfies the constraint.

Let’s suppose it does.

[ slide 138 ]

Page 139: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Uses a Constraint

i i

Now here’s how TLC computes reachable states when it has a stateconstraint.

Starting from the set of initial states. It chooses one and then checks if thestate satisfies the constraint.

Let’s suppose it does.

[ slide 139 ]

Page 140: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Uses a Constraint

i ir

Now here’s how TLC computes reachable states when it has a stateconstraint.

Starting from the set of initial states. It chooses one and then checks if thestate satisfies the constraint.

Let’s suppose it does.

[ slide 140 ]

Page 141: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Uses a Constraint

i xi

Now here’s how TLC computes reachable states when it has a stateconstraint.

Starting from the set of initial states. It chooses one and then checks if thestate satisfies the constraint.

Let’s suppose it does.

[ slide 141 ]

Page 142: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Uses a Constraint

i xii i

iiK�

R�

As before, TLC then computes all possible next states from that state

and chooses another state to explore. It checks if that state satisfies theconstraint Again, let’s suppose it does.

[ slide 142 ]

Page 143: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Uses a Constraint

ir ii i

iiK�

R�

As before, TLC then computes all possible next states from that state

and chooses another state to explore. It checks if that state satisfies theconstraint Again, let’s suppose it does.

[ slide 143 ]

Page 144: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Uses a Constraint

xi ii i

iiK�

R�

As before, TLC then computes all possible next states from that state

and chooses another state to explore. It checks if that state satisfies theconstraint Again, let’s suppose it does.

[ slide 144 ]

Page 145: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Uses a Constraint

xi ii i

iiii �

IK�

R�

TLC then finds all possible next states from it.

It keeps going like this

As long as it finds states that satisfy the constraint.

Suppose it now finds a state that doesn’t satisfy the constraint.

[ slide 145 ]

Page 146: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Uses a Constraint

i iir i

iiii �

IK�

R�

TLC then finds all possible next states from it.

It keeps going like this

As long as it finds states that satisfy the constraint.

Suppose it now finds a state that doesn’t satisfy the constraint.

[ slide 146 ]

Page 147: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Uses a Constraint

i ixi i

iiii �

IK�

R�

TLC then finds all possible next states from it.

It keeps going like this

As long as it finds states that satisfy the constraint.

Suppose it now finds a state that doesn’t satisfy the constraint.

[ slide 147 ]

Page 148: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Uses a Constraint

i ixi i

iiiii i i i

IK�

R�

Y M � 1

TLC then finds all possible next states from it.

It keeps going like this

As long as it finds states that satisfy the constraint.

Suppose it now finds a state that doesn’t satisfy the constraint.

[ slide 148 ]

Page 149: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Uses a Constraint

i ii ir

iiiii i i i

IK�

R�

Y M � 1

TLC then finds all possible next states from it.

It keeps going like this

As long as it finds states that satisfy the constraint.

Suppose it now finds a state that doesn’t satisfy the constraint.

[ slide 149 ]

Page 150: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Uses a Constraint

i ii ix×

iiiii i i i

IK�

R�

Y M � 1

TLC then finds all possible next states from it.

It keeps going like this

As long as it finds states that satisfy the constraint.

Suppose it now finds a state that doesn’t satisfy the constraint.

[ slide 150 ]

Page 151: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Uses a Constraint

i ii i

iriiii i i i

IK�

R�

Y M � 1

It doesn’t explore further from that state and instead just goes on to the nextunexplored state, exploring that state if it satisfies the constraint.

And continuing like that, exploring only states that satisfy the constraint, untilit finds no more states to explore.

[ slide 151 ]

Page 152: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Uses a Constraint

i ii i

xiiiii i i i

IK�

R�

Y M � 1

It doesn’t explore further from that state and instead just goes on to the nextunexplored state, exploring that state if it satisfies the constraint.

And continuing like that, exploring only states that satisfy the constraint, untilit finds no more states to explore.

[ slide 152 ]

Page 153: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Uses a Constraint

i ii i

xiiiii i i i

iii

IK�

R�

Y M � 1

j?

It doesn’t explore further from that state and instead just goes on to the nextunexplored state, exploring that state if it satisfies the constraint.

And continuing like that, exploring only states that satisfy the constraint, untilit finds no more states to explore.

[ slide 153 ]

Page 154: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Uses a Constraint

i ii i

iiriii i i i

iii

IK�

R�

Y M � 1

j?

It doesn’t explore further from that state and instead just goes on to the nextunexplored state, exploring that state if it satisfies the constraint.

And continuing like that, exploring only states that satisfy the constraint, untilit finds no more states to explore.

[ slide 154 ]

Page 155: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Uses a Constraint

i ii i

ix×iiii i i i

iii

IK�

R�

Y M � 1

j?

It doesn’t explore further from that state and instead just goes on to the nextunexplored state, exploring that state if it satisfies the constraint.

And continuing like that, exploring only states that satisfy the constraint, untilit finds no more states to explore.

[ slide 155 ]

Page 156: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

How TLC Uses a Constraint

i ii i

iiirii i i i

iii

IK�

R�

Y M � 1

j?

It doesn’t explore further from that state and instead just goes on to the nextunexplored state, exploring that state if it satisfies the constraint.

And continuing like that, exploring only states that satisfy the constraint, untilit finds no more states to explore.

[ slide 156 ]

Page 157: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

You can now run TLC on your model.

You can now run TLC on your model.

The alternating bit protocol should implement its high-level specification,which means that formula Spec of module AB should imply formula Spec ofmodule ABSpec.

This should be a theorem of module AB that TLC can check, but how canwe write it?

[ slide 157 ]

Page 158: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The AB protocol should implement its high-levelspecification, so formula Spec of module AB

should imply formula Spec of module ABSpec .

This should be a theorem of module AB ,but how can we write it?

INSTANCE ABSpec

is illegal in module AB because it imports definitions ofSpec, . . . , which are already defined in AB .

You can now run TLC on your model.

The alternating bit protocol should implement its high-level specification,which means that formula Spec of module AB should imply formula Spec ofmodule ABSpec.

This should be a theorem of module AB that TLC can check, but how canwe write it?

[ slide 158 ]

Page 159: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The AB protocol should implement its high-levelspecification, so formula Spec of module AB

should imply formula Spec of module ABSpec .

This should be a theorem of module AB ,but how can we write it?

INSTANCE ABSpec

is illegal in module AB because it imports definitions ofSpec, . . . , which are already defined in AB .

You can now run TLC on your model.

The alternating bit protocol should implement its high-level specification,which means that formula Spec of module AB should imply formula Spec ofmodule ABSpec.

This should be a theorem of module AB that TLC can check, but how canwe write it?

[ slide 159 ]

Page 160: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The AB protocol should implement its high-levelspecification, so formula Spec of module AB

should imply formula Spec of module ABSpec .

This should be a theorem of module AB ,but how can we write it?

INSTANCE ABSpec

is illegal in module AB because it imports definitions ofSpec, . . . , which are already defined in AB .

You can now run TLC on your model.

The alternating bit protocol should implement its high-level specification,which means that formula Spec of module AB should imply formula Spec ofmodule ABSpec.

This should be a theorem of module AB that TLC can check, but how canwe write it?

[ slide 160 ]

Page 161: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The AB protocol should implement its high-levelspecification, so formula Spec of module AB

should imply formula Spec of module ABSpec .

This should be a theorem of module AB ,but how can we write it?

INSTANCE ABSpec

is illegal in module AB because it imports definitions ofSpec, . . . , which are already defined in AB .

You can now run TLC on your model.

The alternating bit protocol should implement its high-level specification,which means that formula Spec of module AB should imply formula Spec ofmodule ABSpec.

This should be a theorem of module AB that TLC can check, but how canwe write it?

[ slide 161 ]

Page 162: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The AB protocol should implement its high-levelspecification, so formula Spec of module AB

should imply formula Spec of module ABSpec .

This should be a theorem of module AB ,but how can we write it?

INSTANCE ABSpec

is illegal in module AB because it imports definitions ofSpec, . . . , which are already defined in AB .

The statement “INSTANCE ABSpec” is illegal in module AB because itimports definitions of identifiers like Spec, which are already defined in AB .

[ slide 162 ]

Page 163: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

ABS∆= INSTANCE ABSpec

Imports definitions of Spec, . . . from ABSpec

renamed as ABS !Spec, . . . .

THEOREM Spec ⇒ ABS !Spec

Module AB contains the statement: A-B-S is defined to equal thisinstantiation.

This statement imports into module AB all the definitions, such as that ofSpec, from module ABSpec except renaming them by prefacing their nameswith A-B-S-bang.

[ slide 163 ]

Page 164: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

ABS∆= INSTANCE ABSpec

Imports definitions of Spec, . . . from ABSpec

renamed as ABS !Spec, . . . .

THEOREM Spec ⇒ ABS !Spec

Module AB contains the statement: A-B-S is defined to equal thisinstantiation.

This statement imports into module AB all the definitions, such as that ofSpec, from module ABSpec except renaming them by prefacing their nameswith A-B-S-bang.

[ slide 164 ]

Page 165: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

ABS∆= INSTANCE ABSpec

Imports definitions of Spec, . . . from ABSpec

renamed as ABS !Spec, . . . .

THEOREM Spec ⇒ ABS !Spec

Module AB contains the statement: A-B-S is defined to equal thisinstantiation.

This statement imports into module AB all the definitions, such as that ofSpec, from module ABSpec except renaming them by prefacing their nameswith A-B-S-bang.

[ slide 165 ]

Page 166: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

ABS∆= INSTANCE ABSpec

Imports definitions of Spec, . . . from ABSpec

renamed as ABS !Spec, . . . .

THEOREM Spec ⇒ ABS !Spec

This theorem states that the safety specification of the alternating bit protocolimplements its high-level safety specification from module ABSpec.

TLC will verify it by checking that specification Spec satisfies the temporalproperty A-B-S bang spec .

[ slide 166 ]

Page 167: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

ABS∆= INSTANCE ABSpec

Imports definitions of Spec, . . . from ABSpec

renamed as ABS !Spec, . . . .

THEOREM Spec ⇒ ABS !Spec

This theorem states that the safety specification of the alternating bit protocolimplements its high-level safety specification from module ABSpec.

TLC will verify it by checking that specification Spec satisfies the temporalproperty A-B-S bang spec .

[ slide 167 ]

Page 168: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

LIVENESS

[ slide 168 ]

Page 169: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The complete AB protocol specification should be

The complete protocol specification should be a formula we’ll call FairSpecthat’s the conjunction of the safety spec and one or more fairness properties.

These fairness properties should imply that messages keep getting sent andreceived.

[ slide 169 ]

Page 170: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The complete AB protocol specification should be

FairSpec∆= Spec ∧ fairness properties

The complete protocol specification should be a formula we’ll call FairSpecthat’s the conjunction of the safety spec and one or more fairness properties.

These fairness properties should imply that messages keep getting sent andreceived.

[ slide 170 ]

Page 171: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ fairness properties

Should imply that messageskeep getting sent and received.

The complete protocol specification should be a formula we’ll call FairSpecthat’s the conjunction of the safety spec and one or more fairness properties.

These fairness properties should imply that messages keep getting sent andreceived.

[ slide 171 ]

Page 172: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ fairness properties

Should imply that messageskeep getting sent and received.

THEOREM FairSpec ⇒ ABS !FairSpec

Which means that this theorem should be true.

[ slide 172 ]

Page 173: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ fairness properties

Which means that this theorem should be true.

[ slide 173 ]

Page 174: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ WFvars(Next)

Weak fairness of the Next action doesn’t work.

For example, it allows a behavior in which B just keeps sendingacknowledgments

and nothing else ever happens.

So we need a stronger fairness property.

[ slide 174 ]

Page 175: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ WFvars(Next)

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

Weak fairness of the Next action doesn’t work.

For example, it allows a behavior in which B just keeps sendingacknowledgments

and nothing else ever happens.

So we need a stronger fairness property.

[ slide 175 ]

Page 176: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ WFvars(Next)

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

Weak fairness of the Next action doesn’t work.

For example, it allows a behavior in which B just keeps sendingacknowledgments

and nothing else ever happens.

So we need a stronger fairness property.

[ slide 176 ]

Page 177: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ WFvars(Next)

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

11

Weak fairness of the Next action doesn’t work.

For example, it allows a behavior in which B just keeps sendingacknowledgments

and nothing else ever happens.

So we need a stronger fairness property.

[ slide 177 ]

Page 178: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ WFvars(Next)

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

111

Weak fairness of the Next action doesn’t work.

For example, it allows a behavior in which B just keeps sendingacknowledgments

and nothing else ever happens.

So we need a stronger fairness property.

[ slide 178 ]

Page 179: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ WFvars(Next)

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1111

Weak fairness of the Next action doesn’t work.

For example, it allows a behavior in which B just keeps sendingacknowledgments

and nothing else ever happens.

So we need a stronger fairness property.

[ slide 179 ]

Page 180: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ WFvars(Next)

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

11111

Weak fairness of the Next action doesn’t work.

For example, it allows a behavior in which B just keeps sendingacknowledgments

and nothing else ever happens.

So we need a stronger fairness property.

[ slide 180 ]

Page 181: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ WFvars(Next)

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

111111

Weak fairness of the Next action doesn’t work.

For example, it allows a behavior in which B just keeps sendingacknowledgments

and nothing else ever happens.

So we need a stronger fairness property.

[ slide 181 ]

Page 182: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ fairness properties

Weak fairness of the Next action doesn’t work.

For example, it allows a behavior in which B just keeps sendingacknowledgments

and nothing else ever happens.

So we need a stronger fairness property.

[ slide 182 ]

Page 183: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ fairness properties

Next∆= ASnd ∨ ARcv ∨ BSnd ∨ BRcv ∨ LoseMsg

Remember the definition of the next-state action.

We need separate fairness requirements on these four subactions, to makesure that each of them keeps being executed.

We don’t want any fairness requirement on the Lose-Message actionbecause we don’t want to require that messages have to be lost.

So, let’s try weak fairness of these actions.

[ slide 183 ]

Page 184: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ fairness properties

Next∆= ASnd ∨ ARcv ∨ BSnd ∨ BRcv ∨ LoseMsg

Remember the definition of the next-state action.

We need separate fairness requirements on these four subactions, to makesure that each of them keeps being executed.

We don’t want any fairness requirement on the Lose-Message actionbecause we don’t want to require that messages have to be lost.

So, let’s try weak fairness of these actions.

[ slide 184 ]

Page 185: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ fairness properties

Next∆= ASnd ∨ ARcv ∨ BSnd ∨ BRcv ∨ LoseMsg

Remember the definition of the next-state action.

We need separate fairness requirements on these four subactions, to makesure that each of them keeps being executed.

We don’t want any fairness requirement on the Lose-Message actionbecause we don’t want to require that messages have to be lost.

So, let’s try weak fairness of these actions.

[ slide 185 ]

Page 186: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ fairness properties

Next∆= ASnd ∨ ARcv ∨ BSnd ∨ BRcv ∨ LoseMsg

Remember the definition of the next-state action.

We need separate fairness requirements on these four subactions, to makesure that each of them keeps being executed.

We don’t want any fairness requirement on the Lose-Message actionbecause we don’t want to require that messages have to be lost.

So, let’s try weak fairness of these actions.

[ slide 186 ]

Page 187: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ SFvars(ARcv) ∧ SFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

Module AB contains this definition.

Change it by replacing these two ess-es by double-ewes.

This is a plausible specification, so let’s check if it satisfies this theorem.

[ slide 187 ]

Page 188: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ SFvars(ARcv) ∧ SFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

Module AB contains this definition.

Change it by replacing these two ess-es by double-ewes.

This is a plausible specification, so let’s check if it satisfies this theorem.

[ slide 188 ]

Page 189: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ WFvars(ARcv) ∧WFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

Module AB contains this definition.

Change it by replacing these two ess-es by double-ewes.

This is a plausible specification, so let’s check if it satisfies this theorem.

[ slide 189 ]

Page 190: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ WFvars(ARcv) ∧WFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

THEOREM FairSpec ⇒ ABS !FairSpec

Module AB contains this definition.

Change it by replacing these two ess-es by double-ewes.

This is a plausible specification, so let’s check if it satisfies this theorem.

[ slide 190 ]

Page 191: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Clone your model (removing any symmetry set).

Modify the specification and property to check.

Make a clone of the model you used before (removing any symmetry set).

In the clone, modify the specification and property to check by replacing Spec

with FairSpec.

[ slide 191 ]

Page 192: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Clone your model (removing any symmetry set).

Modify the specification and property to check.

Make a clone of the model you used before (removing any symmetry set).

In the clone, modify the specification and property to check by replacing Spec

with FairSpec.

[ slide 192 ]

Page 193: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Run TLC on the model.

It reports that the temporal property was violatedand produces a counterexample.

Run TLC on the model.

It reports that the temporal property was violatedand produces a counterexample.

[ slide 193 ]

Page 194: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Run TLC on the model.

It reports that the temporal property was violatedand produces a counterexample.

Run TLC on the model.

It reports that the temporal property was violatedand produces a counterexample.

[ slide 194 ]

Page 195: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Run TLC on the model.

It reports that the temporal property was violatedand produces a counterexample.

Run TLC on the model.

It reports that the temporal property was violatedand produces a counterexample.

[ slide 195 ]

Page 196: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 196 ]

Page 197: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 197 ]

Page 198: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

〈“ ”, 1〉

1

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 198 ]

Page 199: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 199 ]

Page 200: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 200 ]

Page 201: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 201 ]

Page 202: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

〈“ ”, 1〉

1

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 202 ]

Page 203: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 203 ]

Page 204: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 204 ]

Page 205: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 205 ]

Page 206: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

〈“ ”, 1〉

1

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 206 ]

Page 207: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 207 ]

Page 208: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

Here’s the counterexample that TLC finds.

B sends an acknowledgment, A sends its value, A’s message is lost, B’smessage is lost, B sends a message, A sends a message, A’s message islost, B’s message is lost, B sends a message, A sends a message, A’smessage is lost, B’s message is lost.

And this continues forever.

[ slide 208 ]

Page 209: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

WFvars(ASnd) and WFvars(BSnd) are truebecause ASnd and BSnd steps keep occurring.

Weak fairness of A-send and B-send are true for this behavior becauseA-send and B-send steps keep occurring.

What about weak fairness of A-receive?

A-receive is not enabled in the initial state, since BtoA contains nomessages.

It becomes enabled when B sends a message.

[ slide 209 ]

Page 210: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

What about WFvars(ARcv)?

Weak fairness of A-send and B-send are true for this behavior becauseA-send and B-send steps keep occurring.

What about weak fairness of A-receive?

A-receive is not enabled in the initial state, since BtoA contains nomessages.

It becomes enabled when B sends a message.

[ slide 210 ]

Page 211: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

ARcv : not enabled

What about WFvars(ARcv)?

Weak fairness of A-send and B-send are true for this behavior becauseA-send and B-send steps keep occurring.

What about weak fairness of A-receive?

A-receive is not enabled in the initial state, since BtoA contains nomessages.

It becomes enabled when B sends a message.

[ slide 211 ]

Page 212: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

ARcv : not enabled

What about WFvars(ARcv)?

Weak fairness of A-send and B-send are true for this behavior becauseA-send and B-send steps keep occurring.

What about weak fairness of A-receive?

A-receive is not enabled in the initial state, since BtoA contains nomessages.

It becomes enabled when B sends a message.

[ slide 212 ]

Page 213: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

〈“ ”, 1〉

1

ARcv : not enabled

What about WFvars(ARcv)?

Weak fairness of A-send and B-send are true for this behavior becauseA-send and B-send steps keep occurring.

What about weak fairness of A-receive?

A-receive is not enabled in the initial state, since BtoA contains nomessages.

It becomes enabled when B sends a message.

[ slide 213 ]

Page 214: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

ARcv : not enabled

What about WFvars(ARcv)?

Weak fairness of A-send and B-send are true for this behavior becauseA-send and B-send steps keep occurring.

What about weak fairness of A-receive?

A-receive is not enabled in the initial state, since BtoA contains nomessages.

It becomes enabled when B sends a message.

[ slide 214 ]

Page 215: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

ARcv : not enabled

What about WFvars(ARcv)?

It becomes disabled when that message is lost.

It becomes enabled again when B sends another message.

It is disabled again when that message is lost.

It becomes enabled again when B sends yet another message.

It’s disabled again when that message is lost. And so on.

[ slide 215 ]

Page 216: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

ARcv : not enabled

What about WFvars(ARcv)?

It becomes disabled when that message is lost.

It becomes enabled again when B sends another message.

It is disabled again when that message is lost.

It becomes enabled again when B sends yet another message.

It’s disabled again when that message is lost. And so on.

[ slide 216 ]

Page 217: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

〈“ ”, 1〉

1

ARcv : not enabled

What about WFvars(ARcv)?

It becomes disabled when that message is lost.

It becomes enabled again when B sends another message.

It is disabled again when that message is lost.

It becomes enabled again when B sends yet another message.

It’s disabled again when that message is lost. And so on.

[ slide 217 ]

Page 218: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

ARcv : not enabled

What about WFvars(ARcv)?

It becomes disabled when that message is lost.

It becomes enabled again when B sends another message.

It is disabled again when that message is lost.

It becomes enabled again when B sends yet another message.

It’s disabled again when that message is lost. And so on.

[ slide 218 ]

Page 219: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

ARcv : not enabled

What about WFvars(ARcv)?

It becomes disabled when that message is lost.

It becomes enabled again when B sends another message.

It is disabled again when that message is lost.

It becomes enabled again when B sends yet another message.

It’s disabled again when that message is lost. And so on.

[ slide 219 ]

Page 220: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

ARcv : not enabled

What about WFvars(ARcv)?

It becomes disabled when that message is lost.

It becomes enabled again when B sends another message.

It is disabled again when that message is lost.

It becomes enabled again when B sends yet another message.

It’s disabled again when that message is lost. And so on.

[ slide 220 ]

Page 221: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

〈“ ”, 1〉

1

ARcv : not enabled

What about WFvars(ARcv)?

It becomes disabled when that message is lost.

It becomes enabled again when B sends another message.

It is disabled again when that message is lost.

It becomes enabled again when B sends yet another message.

It’s disabled again when that message is lost. And so on.

[ slide 221 ]

Page 222: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

1

ARcv : not enabled

What about WFvars(ARcv)?

It becomes disabled when that message is lost.

It becomes enabled again when B sends another message.

It is disabled again when that message is lost.

It becomes enabled again when B sends yet another message.

It’s disabled again when that message is lost. And so on.

[ slide 222 ]

Page 223: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

ARcv : not enabled

What about WFvars(ARcv)?

It becomes disabled when that message is lost.

It becomes enabled again when B sends another message.

It is disabled again when that message is lost.

It becomes enabled again when B sends yet another message.

It’s disabled again when that message is lost. And so on.

[ slide 223 ]

Page 224: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

ARcv : not enabled

What about WFvars(ARcv)?

So weak fairness of A-receive is true on this behavior

because A-receive keeps getting disabled after it’s enabled, and it’s nevercontinuously enabled.

Weak fairness of B-receive is also true on this behavior for the same reason.

[ slide 224 ]

Page 225: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

ARcv : not enabled

What about WFvars(ARcv)? True

So weak fairness of A-receive is true on this behavior

because A-receive keeps getting disabled after it’s enabled, and it’s nevercontinuously enabled.

Weak fairness of B-receive is also true on this behavior for the same reason.

[ slide 225 ]

Page 226: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

ARcv : not enabled

What about WFvars(ARcv)? Truebecause ARcv never continuously enabled.

So weak fairness of A-receive is true on this behavior

because A-receive keeps getting disabled after it’s enabled, and it’s nevercontinuously enabled.

Weak fairness of B-receive is also true on this behavior for the same reason.

[ slide 226 ]

Page 227: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A B

AVar : BVar :

-AtoB

� BtoA

〈“ ”, 1〉 〈“ ”, 1〉

ARcv : not enabled

WFvars(BRcv) is also true.

So weak fairness of A-receive is true on this behavior

because A-receive keeps getting disabled after it’s enabled, and it’s nevercontinuously enabled.

Weak fairness of B-receive is also true on this behavior for the same reason.

[ slide 227 ]

Page 228: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The behavior satisfies FairSpec , defined by:

FairSpec∆= Spec ∧ WFvars(ARcv) ∧WFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

but doesn’t satisfy ABS !FairSpec .

((((((((

(((((((

((((

(((((((

(((((((

(((((hhhhhhhhhhhhhhhhhhh

hhhhhhhhhhhhhhhhhhhTHEOREM FairSpec ⇒ ABS !FairSpec

The behavior satisfies FairSpec , when it’s defined like this.

but it doesn’t satisfy the high level fair spec in module ABSpec because novalues are ever sent from A to B.

So this theorem is not true.

[ slide 228 ]

Page 229: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The behavior satisfies FairSpec , defined by:

FairSpec∆= Spec ∧ WFvars(ARcv) ∧WFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

but doesn’t satisfy ABS !FairSpec .

((((((((

(((((((

((((

(((((((

(((((((

(((((hhhhhhhhhhhhhhhhhhh

hhhhhhhhhhhhhhhhhhhTHEOREM FairSpec ⇒ ABS !FairSpec

The behavior satisfies FairSpec , when it’s defined like this.

but it doesn’t satisfy the high level fair spec in module ABSpec because novalues are ever sent from A to B.

So this theorem is not true.

[ slide 229 ]

Page 230: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The behavior satisfies FairSpec , defined by:

FairSpec∆= Spec ∧ WFvars(ARcv) ∧WFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

but doesn’t satisfy ABS !FairSpec .

((((((((

(((((((

((((

(((((((

(((((((

(((((hhhhhhhhhhhhhhhhhhh

hhhhhhhhhhhhhhhhhhhTHEOREM FairSpec ⇒ ABS !FairSpec

The behavior satisfies FairSpec , when it’s defined like this.

but it doesn’t satisfy the high level fair spec in module ABSpec because novalues are ever sent from A to B.

So this theorem is not true.

[ slide 230 ]

Page 231: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

The behavior satisfies FairSpec , defined by:

FairSpec∆= Spec ∧ WFvars(ARcv) ∧WFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

but doesn’t satisfy ABS !FairSpec .

((((((((

(((((((

((((

(((((((

(((((((

(((((hhhhhhhhhhhhhhhhhhh

hhhhhhhhhhhhhhhhhhhTHEOREM FairSpec ⇒ ABS !FairSpec

The behavior satisfies FairSpec , when it’s defined like this.

but it doesn’t satisfy the high level fair spec in module ABSpec because novalues are ever sent from A to B.

So this theorem is not true.

[ slide 231 ]

Page 232: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ WFvars(ARcv) ∧WFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

Don’t imply ARcv or BRcv steps ever occur,because actions keep getting disabled.

The problem is that

these weak fairness conditions don’t imply that any A-receive or B-recievesteps ever occur, because those actions keep getting disabled.

[ slide 232 ]

Page 233: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ WFvars(ARcv) ∧WFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

Don’t imply ARcv or BRcv steps ever occur,because actions keep getting disabled.

The problem is that

these weak fairness conditions don’t imply that any A-receive or B-recievesteps ever occur, because those actions keep getting disabled.

[ slide 233 ]

Page 234: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42 → s43 → s44 → s45 → s46 → s47 → s48 → s49 → s50 → · · ·A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

Remember that weak fairness of A means if A ever remains continuouslyenabled, then an A step must eventually occur.

Strong fairness of A means that if A ever is repeatedly enabled, then an A

step must eventually occur.

[ slide 234 ]

Page 235: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42 → s43 → s44 → s45 → s46 → s47 → s48 → s49 → s50 → · · ·A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

Remember that weak fairness of A means if A ever remains continuouslyenabled, then an A step must eventually occur.

Strong fairness of A means that if A ever is repeatedly enabled, then an A

step must eventually occur.

[ slide 235 ]

Page 236: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42 → s43 → s44 → s45 → s46 → s47 → s48 → s49 → s50 → · · ·A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

For example, suppose we have a behavior, and A enabled is false in thisstate, then true, the false again, then true, then false and so on,

[ slide 236 ]

Page 237: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42 → s43 → s44 → s45 → s46 → s47 → s48 → s49 → s50 → · · ·A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

For example, suppose we have a behavior, and A enabled is false in thisstate, then true, the false again, then true, then false and so on,

[ slide 237 ]

Page 238: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42

false→ s43 → s44 → s45 → s46 → s47 → s48 → s49 → s50 → · · ·

A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

For example, suppose we have a behavior, and A enabled is false in thisstate, then true, the false again, then true, then false and so on,

[ slide 238 ]

Page 239: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42

false→ s43

true→ s44 → s45 → s46 → s47 → s48 → s49 → s50 → · · ·

A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

For example, suppose we have a behavior, and A enabled is false in thisstate, then true, the false again, then true, then false and so on,

[ slide 239 ]

Page 240: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42

false→ s43

true→ s44

false→ s45 → s46 → s47 → s48 → s49 → s50 → · · ·

A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

For example, suppose we have a behavior, and A enabled is false in thisstate, then true, the false again, then true, then false and so on,

[ slide 240 ]

Page 241: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42

false→ s43

true→ s44

false→ s45

true→ s46 → s47 → s48 → s49 → s50 → · · ·

A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

For example, suppose we have a behavior, and A enabled is false in thisstate, then true, the false again, then true, then false and so on,

[ slide 241 ]

Page 242: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42

false→ s43

true→ s44

false→ s45

true→ s46

false→ s47 → s48 → s49 → s50 → · · ·

A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

For example, suppose we have a behavior, and A enabled is false in thisstate, then true, the false again, then true, then false and so on,

[ slide 242 ]

Page 243: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42

false→ s43

true→ s44

false→ s45

true→ s46

false→ s47

true→ s48 → s49 → s50 → · · ·

A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

For example, suppose we have a behavior, and A enabled is false in thisstate, then true, the false again, then true, then false and so on,

[ slide 243 ]

Page 244: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42

false→ s43

true→ s44

false→ s45

true→ s46

false→ s47

true→ s48

false→ s49 → s50 → · · ·

A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

For example, suppose we have a behavior, and A enabled is false in thisstate, then true, the false again, then true, then false and so on,

[ slide 244 ]

Page 245: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42

false→ s43

true→ s44

false→ s45

true→ s46

false→ s47

true→ s48

false→ s49

false→ s50 → · · ·

A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

For example, suppose we have a behavior, and A enabled is false in thisstate, then true, the false again, then true, then false and so on,

[ slide 245 ]

Page 246: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42

false→ s43

true→ s44

false→ s45

true→ s46

false→ s47

true→ s48

false→ s49

false→ s50

true→ · · ·

A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

For example, suppose we have a behavior, and A enabled is false in thisstate, then true, the false again, then true, then false and so on,

[ slide 246 ]

Page 247: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42

false→ s43

true→ s44

false→ s45

true→ s46

false→ s47

true→ s48

false→ s49

false→ s50

true→ · · ·

A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

where it keeps being re-enabled after it becomes disabled.

Then an A step must eventually occur.

An equivalent way of saying this is that A cannot be repeatedly enabledforever without another A step occurring.

[ slide 247 ]

Page 248: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

WeakStrong

fairness of action A asserts of a behavior:

If A ever remains continuouslyis repeatedly

enabled,then an A step must eventually occur.

· · · → s42

false→ s43

true→ s44

false→ s45

true→ s46

false→ s47

true→ s48

false→ s49

false→ s50

true→ · · ·

A enabled:

Or equivalently:

A cannot be repeatedly enabled foreverwithout another A step occurring.

where it keeps being re-enabled after it becomes disabled.

Then an A step must eventually occur.

An equivalent way of saying this is that A cannot be repeatedly enabledforever without another A step occurring.

[ slide 248 ]

Page 249: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ WFvars(ARcv) ∧WFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

We need to change the definition of FairSpec to what it was originallychanging these weak fairness conditions to strong fairness.

Since the B -send action is always enabled, weak fairness of B -send impliesthat B keeps sending messages. This keeps enabling A-receive which, bystrong fairness implies that A-receive steps must eventually occur to receivethose messages — even if Lose-message actions keep disabling A-receive.

[ slide 249 ]

Page 250: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ WFvars(ARcv) ∧WFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

We need to change the definition of FairSpec to what it was originallychanging these weak fairness conditions to strong fairness.

Since the B -send action is always enabled, weak fairness of B -send impliesthat B keeps sending messages. This keeps enabling A-receive which, bystrong fairness implies that A-receive steps must eventually occur to receivethose messages — even if Lose-message actions keep disabling A-receive.

[ slide 250 ]

Page 251: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ SFvars(ARcv) ∧ SFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

We need to change the definition of FairSpec to what it was originallychanging these weak fairness conditions to strong fairness.

Since the B -send action is always enabled, weak fairness of B -send impliesthat B keeps sending messages. This keeps enabling A-receive which, bystrong fairness implies that A-receive steps must eventually occur to receivethose messages — even if Lose-message actions keep disabling A-receive.

[ slide 251 ]

Page 252: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ SFvars(ARcv) ∧ SFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

B must keep sending messageswhich implies A must eventuallyreceive those messages.

We need to change the definition of FairSpec to what it was originallychanging these weak fairness conditions to strong fairness.

Since the B -send action is always enabled, weak fairness of B -send impliesthat B keeps sending messages. This keeps enabling A-receive which, bystrong fairness implies that A-receive steps must eventually occur to receivethose messages — even if Lose-message actions keep disabling A-receive.

[ slide 252 ]

Page 253: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ SFvars(ARcv) ∧ SFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

B must keep sending messageswhich implies A must eventuallyreceive those messages.

We need to change the definition of FairSpec to what it was originallychanging these weak fairness conditions to strong fairness.

Since the B -send action is always enabled, weak fairness of B -send impliesthat B keeps sending messages. This keeps enabling A-receive which, bystrong fairness implies that A-receive steps must eventually occur to receivethose messages — even if Lose-message actions keep disabling A-receive.

[ slide 253 ]

Page 254: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ SFvars(ARcv) ∧ SFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

A must keep sending messagesthat B must eventually receive.

Similarly, A must keep sending messages that B must eventually receive.

With this definition, the theorem is true.

You can change the definition of FairSpec in the module and rerun the model,and TLC will now find no error.[ slide 254 ]

Page 255: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ SFvars(ARcv) ∧ SFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

A must keep sending messagesthat B must eventually receive.

Similarly, A must keep sending messages that B must eventually receive.

With this definition, the theorem is true.

You can change the definition of FairSpec in the module and rerun the model,and TLC will now find no error.[ slide 255 ]

Page 256: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ SFvars(ARcv) ∧ SFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

Similarly, A must keep sending messages that B must eventually receive.

With this definition, the theorem is true.

You can change the definition of FairSpec in the module and rerun the model,and TLC will now find no error.[ slide 256 ]

Page 257: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ SFvars(ARcv) ∧ SFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

THEOREM FairSpec ⇒ ABS !FairSpec

TLC will now find no error.

Similarly, A must keep sending messages that B must eventually receive.

With this definition, the theorem is true.

You can change the definition of FairSpec in the module and rerun the model,and TLC will now find no error.[ slide 257 ]

Page 258: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

FairSpec∆= Spec ∧ SFvars(ARcv) ∧ SFvars(BRcv) ∧

WFvars(ASnd) ∧WFvars(BSnd)

THEOREM FairSpec ⇒ ABS !FairSpec

TLC will now find no error.

Similarly, A must keep sending messages that B must eventually receive.

With this definition, the theorem is true.

You can change the definition of FairSpec in the module and rerun the model,and TLC will now find no error.[ slide 258 ]

Page 259: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

What Good is Liveness?

What good is knowing that something eventuallyhappens

How can we ensure strong fairness of the ARcv and BRcv

actions? Or ever know that it’s not satisfied?

What Good is Liveness?

What good is knowing that something eventually happens?If it could be a million years from now when it happens.

[ slide 259 ]

Page 260: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

What Good is Liveness?

What good is knowing that something eventuallyhappens?

How can we ensure strong fairness of the ARcv and BRcv

actions? Or ever know that it’s not satisfied?

What Good is Liveness?

What good is knowing that something eventually happens?If it could be a million years from now when it happens.

[ slide 260 ]

Page 261: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

What Good is Liveness?

What good is knowing that something eventuallyhappens – if it could be 106 years from now?

How can we ensure strong fairness of the ARcv and BRcv

actions? Or ever know that it’s not satisfied?

What Good is Liveness?

What good is knowing that something eventually happens?If it could be a million years from now when it happens.

[ slide 261 ]

Page 262: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

What Good is Liveness?

What good is knowing that something eventuallyhappens – if it could be 106 years from now?

How can we ensure strong fairness of the ARcv and BRcv

actions? Or ever know that it’s not satisfied?

How can we ensure strong fairness of the ARcv and BRcv actions?Or ever know that it’s not satisfied? Since it would take forever to be sure thatit’s not.

[ slide 262 ]

Page 263: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

What Good is Liveness?

What good is knowing that something eventuallyhappens – if it could be 106 years from now?

How can we ensure strong fairness of the ARcv and BRcv

actions? Or ever know that it’s not satisfied?

How can we ensure strong fairness of the ARcv and BRcv actions?Or ever know that it’s not satisfied? Since it would take forever to be sure thatit’s not.

[ slide 263 ]

Page 264: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A specification is an abstraction.

It’s a compromise between our desires foraccuracy and simplicity.

We’d like to require that a message is received within 4.7 ms.But that would require specifying:

– How long it can take a message to be received.– How often messages can be lost.– How frequently messages are retransmitted.

A specification is an abstraction.

It’s a compromise between our desires for accuracy and simplicity.

We’d like to require that a message is received within 4.7 milliseconds ofwhen it’s sent.

[ slide 264 ]

Page 265: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A specification is an abstraction.

It’s a compromise between our desires foraccuracy and simplicity.

We’d like to require that a message is received within 4.7 ms.But that would require specifying:

– How long it can take a message to be received.– How often messages can be lost.– How frequently messages are retransmitted.

A specification is an abstraction.

It’s a compromise between our desires for accuracy and simplicity.

We’d like to require that a message is received within 4.7 milliseconds ofwhen it’s sent.

[ slide 265 ]

Page 266: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A specification is an abstraction.

It’s a compromise between our desires foraccuracy and simplicity.

We’d like to require that a message is received within 4.7 ms.But that would require specifying:

– How long it can take a message to be received.– How often messages can be lost.– How frequently messages are retransmitted.

A specification is an abstraction.

It’s a compromise between our desires for accuracy and simplicity.

We’d like to require that a message is received within 4.7 milliseconds ofwhen it’s sent.

[ slide 266 ]

Page 267: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A specification is an abstraction.

It’s a compromise between our desires foraccuracy and simplicity.

We’d like to require that a message is received within 4.7 ms.But that would require specifying:

– How long it can take a message to be received.– How often messages can be lost.– How frequently messages are retransmitted.

But that would require specifying:

How long it can take a message to be received.

How often messages can be lost.

And how frequently messages are retransmitted.

[ slide 267 ]

Page 268: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A specification is an abstraction.

It’s a compromise between our desires foraccuracy and simplicity.

We’d like to require that a message is received within 4.7 ms.But that would require specifying:

– How long it can take a message to be received.– How often messages can be lost.– How frequently messages are retransmitted.

But that would require specifying:

How long it can take a message to be received.

How often messages can be lost.

And how frequently messages are retransmitted.

[ slide 268 ]

Page 269: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A specification is an abstraction.

It’s a compromise between our desires foraccuracy and simplicity.

We’d like to require that a message is received within 4.7 ms.But that would require specifying:

– How long it can take a message to be received.– How often messages can be lost.– How frequently messages are retransmitted.

But that would require specifying:

How long it can take a message to be received.

How often messages can be lost.

And how frequently messages are retransmitted.

[ slide 269 ]

Page 270: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

A specification is an abstraction.

It’s a compromise between our desires foraccuracy and simplicity.

We’d like to require that a message is received within 4.7 ms.But that would require specifying:

– How long it can take a message to be received.– How often messages can be lost.– How frequently messages are retransmitted.

But that would require specifying:

How long it can take a message to be received.

How often messages can be lost.

And how frequently messages are retransmitted.

[ slide 270 ]

Page 271: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

It’s simpler to require that a message iseventually received.

If it’s not eventually received, it can’t be receivedwithin 4.7 ms.

For systems without hard real-time response requirements,liveness checking is a useful way to find errors that preventthings from happening.

It’s simpler to require that a message is eventually received.

And if it’s not eventually received, it certainly can’t be received within 4.7milliseconds.

For systems without hard real-time response requirements,

liveness checking is a useful way to find errors that prevent things fromhappening.

[ slide 271 ]

Page 272: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

It’s simpler to require that a message iseventually received.

If it’s not eventually received, it can’t be receivedwithin 4.7 ms.

For systems without hard real-time response requirements,liveness checking is a useful way to find errors that preventthings from happening.

It’s simpler to require that a message is eventually received.

And if it’s not eventually received, it certainly can’t be received within 4.7milliseconds.

For systems without hard real-time response requirements,

liveness checking is a useful way to find errors that prevent things fromhappening.

[ slide 272 ]

Page 273: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

It’s simpler to require that a message iseventually received.

If it’s not eventually received, it can’t be receivedwithin 4.7 ms.

For systems without hard real-time response requirements,liveness checking is a useful way to find errors that preventthings from happening.

It’s simpler to require that a message is eventually received.

And if it’s not eventually received, it certainly can’t be received within 4.7milliseconds.

For systems without hard real-time response requirements,

liveness checking is a useful way to find errors that prevent things fromhappening.

[ slide 273 ]

Page 274: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

It’s simpler to require that a message iseventually received.

If it’s not eventually received, it can’t be receivedwithin 4.7 ms.

For systems without hard real-time response requirements,liveness checking is a useful way to find errors that preventthings from happening.

It’s simpler to require that a message is eventually received.

And if it’s not eventually received, it certainly can’t be received within 4.7milliseconds.

For systems without hard real-time response requirements,

liveness checking is a useful way to find errors that prevent things fromhappening.

[ slide 274 ]

Page 275: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Many systems use timeouts only to ensure thatsomething must happen.

Correctness of such a system does not dependon how long it takes the timeouts to occur.

Specifications of these systems can describe timeouts as actionswith no time constraints, only weak fairness conditions.

This is true for most systems with no bounds on how long it cantake an enabled operation (such as receiving a message) to occur.

Many systems use timeouts only to ensure that something must happen.By using timeouts only for that purpose, I mean thatcorrectness of such a system does not depend on how long it takes thetimeouts to occur.

That can influence only performance.

[ slide 275 ]

Page 276: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Many systems use timeouts only to ensure thatsomething must happen.

Correctness of such a system does not dependon how long it takes the timeouts to occur.

Specifications of these systems can describe timeouts as actionswith no time constraints, only weak fairness conditions.

This is true for most systems with no bounds on how long it cantake an enabled operation (such as receiving a message) to occur.

Many systems use timeouts only to ensure that something must happen.By using timeouts only for that purpose, I mean thatcorrectness of such a system does not depend on how long it takes thetimeouts to occur.

That can influence only performance.

[ slide 276 ]

Page 277: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Many systems use timeouts only to ensure thatsomething must happen.

Correctness of such a system does not dependon how long it takes the timeouts to occur.

Specifications of these systems can describe timeouts as actionswith no time constraints, only weak fairness conditions.

This is true for most systems with no bounds on how long it cantake an enabled operation (such as receiving a message) to occur.

Many systems use timeouts only to ensure that something must happen.By using timeouts only for that purpose, I mean thatcorrectness of such a system does not depend on how long it takes thetimeouts to occur.

That can influence only performance.

[ slide 277 ]

Page 278: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Many systems use timeouts only to ensure thatsomething must happen.

Correctness of such a system does not dependon how long it takes the timeouts to occur.

That can influence only performance.

Specifications of these systems can describe timeouts as actionswith no time constraints, only weak fairness conditions.

This is true for most systems with no bounds on how long it cantake an enabled operation (such as receiving a message) to occur.

Many systems use timeouts only to ensure that something must happen.By using timeouts only for that purpose, I mean thatcorrectness of such a system does not depend on how long it takes thetimeouts to occur.

That can influence only performance.

[ slide 278 ]

Page 279: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Many systems use timeouts only to ensure thatsomething must happen.

Correctness of such a system does not dependon how long it takes the timeouts to occur.

Specifications of these systems can describe timeouts as actionswith no time constraints, only weak fairness conditions.

This is true for most systems with no bounds on how long it cantake an enabled operation (such as receiving a message) to occur.

Specifications of these systems can describe timeouts as actions with notime constraints, only weak fairness conditions.

This is true for most systems with no bounds on how long it can take anenabled operation (such as receiving a message) to occur.

[ slide 279 ]

Page 280: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

Many systems use timeouts only to ensure thatsomething must happen.

Correctness of such a system does not dependon how long it takes the timeouts to occur.

Specifications of these systems can describe timeouts as actionswith no time constraints, only weak fairness conditions.

This is true for most systems with no bounds on how long it cantake an enabled operation (such as receiving a message) to occur.

Specifications of these systems can describe timeouts as actions with notime constraints, only weak fairness conditions.

This is true for most systems with no bounds on how long it can take anenabled operation (such as receiving a message) to occur.

[ slide 280 ]

Page 281: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

In the first eight lectures, you learned about writing the safety part of a TLA+ spec.Now you know how to specify liveness. You simply add weak and strong fairnessconditions. Simple, yes. Easy, no. Liveness is inherently subtle. TLA+ is the simplestway I know to express it, and it’s still hard.

But don’t worry if you have trouble with liveness. The safety part is by far the largestpart and almost always the most important part of a spec. A major reason to addliveness is to catch errors in the safety part. If your fairness conditions don’t imply theeventually or leads-to properties you expect to hold, it could be because the safety partdoesn’t allow behaviors that it should.[ slide 281 ]

Page 282: THE ALTERNATING BIT PROTOCOL - Microsoft Azure · h “Mary ”;1i h derF 0i “Mary ”; 1i h“Mary ”; 1h i 0 Meanwhile, B acknowledges the last value it received by sending its

TLA+ Video Course

End of Lecture 9, Part 2

THE ALTERNATING BIT PROTOCOLTHE PROTOCOL

[ slide 282 ]