FUNDAMENTALS OF SESSION TYPES Vasco T. Vasconcelos University of - - PowerPoint PPT Presentation

fundamentals of session types
SMART_READER_LITE
LIVE PREVIEW

FUNDAMENTALS OF SESSION TYPES Vasco T. Vasconcelos University of - - PowerPoint PPT Presentation

FUNDAMENTALS OF SESSION TYPES Vasco T. Vasconcelos University of Lisbon Formal Methods for the Design of Computer, Communication and Software Systems Bertinoro, June 4, 2009 1 CHALLENGE Among the many problems faced in developing


slide-1
SLIDE 1

FUNDAMENTALS OF SESSION TYPES

Formal Methods for the Design of Computer, Communication and Software Systems

Bertinoro, June 4, 2009

Vasco T. Vasconcelos University of Lisbon

1

slide-2
SLIDE 2

CHALLENGE

  • Among the many problems faced in developing web-service

based applications, there is a little one that this talk addresses:

  • Formally describing the protocol between a service provider

a client

  • Making sure, at compile time, that a program follows the

protocol

2

slide-3
SLIDE 3

BINARY PROTOCOLS ONLY

  • We concentrate on binary protocols, involving exactly one

service provider and one client (at a time)

  • Protocols demanding three or more partners are the topic of

the next talk

3

slide-4
SLIDE 4

OUTLINE

Part I _ The practice Where, based on an example, we describe a simple service and program it Part 2 _ The theory Where we discusss the technology behind a compiler that makes sure programs conform to service descriptions

4

slide-5
SLIDE 5

PART I THE PRACTICE

5

slide-6
SLIDE 6

1. PROTOCOL DESCRIPTION

6

slide-7
SLIDE 7

OUR RUNNING EXAMPLE

  • A simplified distributed auction system with three kinds of

players:

  • Sellers that want to sell items
  • Auctioneers that sell items on their behalf
  • Bidders that bid for an item being auctioned

7

slide-8
SLIDE 8

THE SELLER’S PROTOCOL

8

slide-9
SLIDE 9

THE SELLER’S PROTOCOL

{selling:

8

slide-10
SLIDE 10

THE SELLER’S PROTOCOL

{selling:

Select option selling on the auctioneer

8

slide-11
SLIDE 11

THE SELLER’S PROTOCOL

{selling:

8

slide-12
SLIDE 12

THE SELLER’S PROTOCOL

{selling: !Item

8

slide-13
SLIDE 13

THE SELLER’S PROTOCOL

{selling: !Item

Send the item to be sold

8

slide-14
SLIDE 14

THE SELLER’S PROTOCOL

{selling: !Item

8

slide-15
SLIDE 15

THE SELLER’S PROTOCOL

{selling: !Item.!Price.

8

slide-16
SLIDE 16

THE SELLER’S PROTOCOL

{selling: !Item.!Price.

Send its price

8

slide-17
SLIDE 17

THE SELLER’S PROTOCOL

{selling: !Item.!Price.

8

slide-18
SLIDE 18

THE SELLER’S PROTOCOL

{selling: !Item.!Price. &{sold:

8

slide-19
SLIDE 19

THE SELLER’S PROTOCOL

{selling: !Item.!Price.

If the item was sold...

&{sold:

8

slide-20
SLIDE 20

THE SELLER’S PROTOCOL

{selling: !Item.!Price. &{sold:

8

slide-21
SLIDE 21

THE SELLER’S PROTOCOL

{selling: !Item.!Price. &{sold: ?Price

8

slide-22
SLIDE 22

THE SELLER’S PROTOCOL

{selling: !Item.!Price.

Read the price

&{sold: ?Price

8

slide-23
SLIDE 23

THE SELLER’S PROTOCOL

{selling: !Item.!Price. &{sold: ?Price

8

slide-24
SLIDE 24

THE SELLER’S PROTOCOL

{selling: !Item.!Price. &{sold: ?Price.end,

8

slide-25
SLIDE 25

THE SELLER’S PROTOCOL

{selling: !Item.!Price.

... and terminate

&{sold: ?Price.end,

8

slide-26
SLIDE 26

THE SELLER’S PROTOCOL

{selling: !Item.!Price. &{sold: ?Price.end,

8

slide-27
SLIDE 27

THE SELLER’S PROTOCOL

{selling: !Item.!Price. &{sold: ?Price.end, notSold: end}}

8

slide-28
SLIDE 28

THE SELLER’S PROTOCOL

{selling: !Item.!Price.

If not sold terminate

&{sold: ?Price.end, notSold: end}}

8

slide-29
SLIDE 29

THE SELLER’S PROTOCOL

{selling: !Item.!Price. &{sold: ?Price.end, notSold: end}}

8

slide-30
SLIDE 30

THE TYPE CONSTRUCTORS

!Item Send a value ?Price Receive a value {selling: ...} Select an option &{sold: ..., notSold: ...} Offer a set of options end Terminate

9

slide-31
SLIDE 31

THE AUCTIONEER INTERACTING WITH A SELLER

10

slide-32
SLIDE 32

THE AUCTIONEER INTERACTING WITH A SELLER

&{selling:

10

slide-33
SLIDE 33

THE AUCTIONEER INTERACTING WITH A SELLER

&{selling:

Offer option selling to sellers

10

slide-34
SLIDE 34

THE AUCTIONEER INTERACTING WITH A SELLER

&{selling:

10

slide-35
SLIDE 35

THE AUCTIONEER INTERACTING WITH A SELLER

&{selling: ?Item.

10

slide-36
SLIDE 36

THE AUCTIONEER INTERACTING WITH A SELLER

&{selling: ?Item.

Receive the item to be sold

10

slide-37
SLIDE 37

THE AUCTIONEER INTERACTING WITH A SELLER

&{selling: ?Item.

10

slide-38
SLIDE 38

THE AUCTIONEER INTERACTING WITH A SELLER

&{selling: ?Item.?Price.

10

slide-39
SLIDE 39

THE AUCTIONEER INTERACTING WITH A SELLER

&{selling: ?Item.?Price.

Receive its price

10

slide-40
SLIDE 40

THE AUCTIONEER INTERACTING WITH A SELLER

&{selling: ?Item.?Price.

10

slide-41
SLIDE 41

THE AUCTIONEER INTERACTING WITH A SELLER

&{selling: ?Item.?Price. {sold:

10

slide-42
SLIDE 42

THE AUCTIONEER INTERACTING WITH A SELLER

&{selling: ?Item.?Price. {sold:

Inform that the item was sold...

10

slide-43
SLIDE 43

THE AUCTIONEER INTERACTING WITH A SELLER

&{selling: ?Item.?Price. {sold:

10

slide-44
SLIDE 44

THE AUCTIONEER INTERACTING WITH A SELLER

&{selling: ?Item.?Price. {sold: !Price

10

slide-45
SLIDE 45

THE AUCTIONEER INTERACTING WITH A SELLER

&{selling: ?Item.?Price. {sold: !Price

Send the selling price

10

slide-46
SLIDE 46

THE AUCTIONEER INTERACTING WITH A SELLER

&{selling: ?Item.?Price. {sold: !Price

10

slide-47
SLIDE 47

THE AUCTIONEER INTERACTING WITH A SELLER

&{selling: ?Item.?Price. {sold: !Price.end,

10

slide-48
SLIDE 48

THE AUCTIONEER INTERACTING WITH A SELLER

&{selling: ?Item.?Price. {sold: !Price.end,

... and terminate

10

slide-49
SLIDE 49

THE AUCTIONEER INTERACTING WITH A SELLER

&{selling: ?Item.?Price. {sold: !Price.end,

10

slide-50
SLIDE 50

THE AUCTIONEER INTERACTING WITH A SELLER

&{selling: ?Item.?Price. {sold: !Price.end, notSold: end}}

10

slide-51
SLIDE 51

THE AUCTIONEER INTERACTING WITH A SELLER

&{selling: ?Item.?Price. {sold: !Price.end, notSold: end}}

Or inform the item was not sold and terminate

10

slide-52
SLIDE 52

THE AUCTIONEER INTERACTING WITH A SELLER

&{selling: ?Item.?Price. {sold: !Price.end, notSold: end}}

10

slide-53
SLIDE 53

SELLING AND BUYING...

  • ... are complementary activities
  • And so are the types that govern them:
  • We call them dual

11

slide-54
SLIDE 54

SELLING AND BUYING...

  • ... are complementary activities
  • And so are the types that govern them:
  • We call them dual

{selling: !Item.!Price.&{sold: ?Price.end, notSold: end}}

11

slide-55
SLIDE 55

SELLING AND BUYING...

  • ... are complementary activities
  • And so are the types that govern them:
  • We call them dual

{selling: !Item.!Price.&{sold: ?Price.end, notSold: end}}

The protocol for the seller

11

slide-56
SLIDE 56

SELLING AND BUYING...

  • ... are complementary activities
  • And so are the types that govern them:
  • We call them dual

{selling: !Item.!Price.&{sold: ?Price.end, notSold: end}} &{selling: ?Item.?Price.{sold: !Price.end, notSold: end}}

The protocol for the seller

11

slide-57
SLIDE 57

SELLING AND BUYING...

  • ... are complementary activities
  • And so are the types that govern them:
  • We call them dual

{selling: !Item.!Price.&{sold: ?Price.end, notSold: end}} &{selling: ?Item.?Price.{sold: !Price.end, notSold: end}}

The protocol for the seller The protocol for the auctioneer

11

slide-58
SLIDE 58

THE BIDDERS PROTOCOL

12

slide-59
SLIDE 59

THE BIDDERS PROTOCOL

{register:

12

slide-60
SLIDE 60

THE BIDDERS PROTOCOL

{register:

Select option register on the auctioneer

12

slide-61
SLIDE 61

THE BIDDERS PROTOCOL

{register:

12

slide-62
SLIDE 62

THE BIDDERS PROTOCOL

{register: !Name.

12

slide-63
SLIDE 63

THE BIDDERS PROTOCOL

{register: !Name.

Send buyer’s name

12

slide-64
SLIDE 64

THE BIDDERS PROTOCOL

{register: !Name.

12

slide-65
SLIDE 65

THE BIDDERS PROTOCOL

{register: !Name. ?Item.

12

slide-66
SLIDE 66

THE BIDDERS PROTOCOL

{register: !Name. ?Item.

Receive an item

  • n sale

12

slide-67
SLIDE 67

THE BIDDERS PROTOCOL

{register: !Name. ?Item.

12

slide-68
SLIDE 68

THE BIDDERS PROTOCOL

{register: !Name. ?Item.?Price.

12

slide-69
SLIDE 69

THE BIDDERS PROTOCOL

{register: !Name. ?Item.?Price.

Receive its price

12

slide-70
SLIDE 70

THE BIDDERS PROTOCOL

{register: !Name. ?Item.?Price.

12

slide-71
SLIDE 71

THE BIDDERS PROTOCOL

{register: !Name. ?Item.?Price. {buy:

12

slide-72
SLIDE 72

THE BIDDERS PROTOCOL

{register: !Name. ?Item.?Price. {buy:

Decided to buy...

12

slide-73
SLIDE 73

THE BIDDERS PROTOCOL

{register: !Name. ?Item.?Price. {buy:

12

slide-74
SLIDE 74

THE BIDDERS PROTOCOL

{register: !Name. ?Item.?Price. {buy:end,

12

slide-75
SLIDE 75

THE BIDDERS PROTOCOL

{register: !Name. ?Item.?Price. {buy:end,

... and terminate

12

slide-76
SLIDE 76

THE BIDDERS PROTOCOL

{register: !Name. ?Item.?Price. {buy:end,

12

slide-77
SLIDE 77

THE BIDDERS PROTOCOL

{register: !Name. ?Item.?Price. {buy:end, notInterested: end}}

12

slide-78
SLIDE 78

THE BIDDERS PROTOCOL

{register: !Name. ?Item.?Price. {buy:end, notInterested: end}}

Decided not to buy; terminate

12

slide-79
SLIDE 79

THE BIDDERS PROTOCOL

{register: !Name. ?Item.?Price. {buy:end, notInterested: end}}

12

slide-80
SLIDE 80

THE AUCTIONEER WHILE INTERACTING WITH BIDDERS

  • Recall the type when interacting with sellers:
  • Two types? one for interacting with sellers, the other for

bidders?

&{register: ?Name.!Item.!Price. &{buy: end, notInterested: end}} &{selling: ?Item.?Price. {sold: !Price.end, notSold: end}}

13

slide-81
SLIDE 81

THE AUCTIONEER ITSELF

  • The particular types used to interact with sellers and with

bidders are subtypes of this type

  • Advantages:
  • Bidders do not need to know the protocol for sellers
  • The code for bidders may be developed before the

introduction of (online) sellers in the auction system

&{register: ?Name. !Item. !Price. &{buy: end, notInterested: end}, selling: ?Item.?Price. {sold: !Price. end, notSold: end}}

14

slide-82
SLIDE 82

COMPATIBILITY

  • The bidder-auctioneer compatibility rest assured. The actual

type for the auctioneer

  • is a supertype of
  • which is dual of that for the bidder

&{register: ?Name. !Item. !Price. &{buy: end, notInterested: end}, selling: ...} &{register: ?Name. !Item. !Price. &{buy: end, notInterested: end}} {register: !Name. ?Item. ?Price. {buy: end, notInterested: end}}

15

slide-83
SLIDE 83

SYSTEM EVOLUTION

  • By far the most common sellers’ complaint is the inability of

lowering the initial price after an unsuccessful auction

  • The new auctioneer now provides a 3rd choice

“We are very excited about your item; would you consider lowering the price?”

&{selling: ?Item.?Price.Selling, register: ...} Selling = {sold: !Price. end, notSold: end,

lowerYourPrice: &{ok: ?Price. Selling,

noWay: end}}

16

slide-84
SLIDE 84

COMPATIBILITY ASSURED?

  • The old seller still works, it just does not use the new

functionality

  • The new type is far more complex than the original: additional

recursion and one more choice. Expanding recursion we see that all there remains is one more choice

&{selling: ?Item. ?Price. {sold: !Price. end, notSold: end, lowerYourPrice&{ok: ?Price. Selling, noWay: end}}}

17

slide-85
SLIDE 85

SUBTYPING

Subtype Supertype Variancy Branch & Selection Input ? Output ! Less options

  • ffered

More options

  • ffered

Covariant More options taken Less options taken Contravariant Input value is subtype Input value is supertype Covariant Output value is supertype Output value is supertype Contravariant

  • In all cases continuation are covariant
  • Recursion “unfolded away” _ co-inductive definition

18

slide-86
SLIDE 86

SESSIONS

  • Protocols such as the seller-auctioneer-bidder run between

exactly two partners at a time:

  • seller-auctioneer, or
  • auctioneer-bidder
  • Each such run is called a session

19

slide-87
SLIDE 87

CHANNELS

  • An auctioneer must be able to conduct multiple sessions in

parallel, with different sellers, with different bidders

  • And must not mix the sessions. E.g.,
  • Announcing sold to bidder A
  • Sending the corresponding Price to bidder B
  • Each session is conducted on a different bi-directional

communication medium called channel

20

slide-88
SLIDE 88

ESTABLISHING SESSIONS

  • How are sessions created?
  • On channels known to all participants potentially interested
  • n online auctions, e.g., distributed on the www
  • We could distinguish
  • linear channels - known by one partner
  • shared channels - known by any number of partners...

21

slide-89
SLIDE 89

CLASSIFYING OPERATIONS

  • ...but we prefer to work with a single kind of channel and

distinguish linear from unrestricted (shared) operations

  • This gives us greater flexibility and a simplified theory
  • All the operations we have seen so far are linear

lin{selling: lin!Item. lin!Price. lin&{sold: lin?Price. un end, notSold: un end}}

The interesting end is unrestricted

22

slide-90
SLIDE 90

BACK TO SESSION ESTABLISHMENT

  • The common knowledge between the three kinds of partners

is a shared channel, used to establish linear sessions

  • Recall the type of the auctioneer’s session
  • The type of the shared channel is

T = lin&{register: ..., selling: ...}

23

slide-91
SLIDE 91

BACK TO SESSION ESTABLISHMENT

  • The common knowledge between the three kinds of partners

is a shared channel, used to establish linear sessions

  • Recall the type of the auctioneer’s session
  • The type of the shared channel is

T = lin&{register: ..., selling: ...} S = un?T.S

23

slide-92
SLIDE 92

BACK TO SESSION ESTABLISHMENT

  • The common knowledge between the three kinds of partners

is a shared channel, used to establish linear sessions

  • Recall the type of the auctioneer’s session
  • The type of the shared channel is

T = lin&{register: ..., selling: ...} S = un?T.S

Establish a session

23

slide-93
SLIDE 93

BACK TO SESSION ESTABLISHMENT

  • The common knowledge between the three kinds of partners

is a shared channel, used to establish linear sessions

  • Recall the type of the auctioneer’s session
  • The type of the shared channel is

T = lin&{register: ..., selling: ...} S = un?T.S

23

slide-94
SLIDE 94

BACK TO SESSION ESTABLISHMENT

  • The common knowledge between the three kinds of partners

is a shared channel, used to establish linear sessions

  • Recall the type of the auctioneer’s session
  • The type of the shared channel is

T = lin&{register: ..., selling: ...} S = un?T.S

Establish more sessions

23

slide-95
SLIDE 95

BACK TO SESSION ESTABLISHMENT

  • The common knowledge between the three kinds of partners

is a shared channel, used to establish linear sessions

  • Recall the type of the auctioneer’s session
  • The type of the shared channel is

T = lin&{register: ..., selling: ...} S = un?T.S

23

slide-96
SLIDE 96

2. PROGRAMMING

24

slide-97
SLIDE 97

WHICH PROGRAMMING LANGUAGE?

  • In which language shall we program the protocol?
  • Functional?
  • Imperative?
  • Object-oriented?
  • You’ll find all flavours in the literature
  • It must incorporate the notion of channels; we shall use a pi-

calculus

25

slide-98
SLIDE 98

PROGRAMMING THE SELLER

c ! selling. c ! “psp”. c ! 100. c "{ sold c?(x).print!(“made “ ^ x ^ “euros!”) notSold print!(“next time I’ll ask 99.9!”) }

26

slide-99
SLIDE 99

PROGRAMMING THE SELLER

c ! selling. c ! “psp”. c ! 100. c "{ sold c?(x).print!(“made “ ^ x ^ “euros!”) notSold print!(“next time I’ll ask 99.9!”) }

c is the name of a channel

26

slide-100
SLIDE 100

PROGRAMMING THE SELLER

c ! selling. c ! “psp”. c ! 100. c "{ sold c?(x).print!(“made “ ^ x ^ “euros!”) notSold print!(“next time I’ll ask 99.9!”) }

26

slide-101
SLIDE 101

PROGRAMMING THE SELLER

c ! selling. c ! “psp”. c ! 100. c "{ sold c?(x).print!(“made “ ^ x ^ “euros!”) notSold print!(“next time I’ll ask 99.9!”) }

Select option selling on the auctioneer

26

slide-102
SLIDE 102

PROGRAMMING THE SELLER

c ! selling. c ! “psp”. c ! 100. c "{ sold c?(x).print!(“made “ ^ x ^ “euros!”) notSold print!(“next time I’ll ask 99.9!”) }

26

slide-103
SLIDE 103

PROGRAMMING THE SELLER

c ! selling. c ! “psp”. c ! 100. c "{ sold c?(x).print!(“made “ ^ x ^ “euros!”) notSold print!(“next time I’ll ask 99.9!”) }

Send the item to be sold

26

slide-104
SLIDE 104

PROGRAMMING THE SELLER

c ! selling. c ! “psp”. c ! 100. c "{ sold c?(x).print!(“made “ ^ x ^ “euros!”) notSold print!(“next time I’ll ask 99.9!”) }

26

slide-105
SLIDE 105

PROGRAMMING THE SELLER

c ! selling. c ! “psp”. c ! 100. c "{ sold c?(x).print!(“made “ ^ x ^ “euros!”) notSold print!(“next time I’ll ask 99.9!”) }

Send its price

26

slide-106
SLIDE 106

PROGRAMMING THE SELLER

c ! selling. c ! “psp”. c ! 100. c "{ sold c?(x).print!(“made “ ^ x ^ “euros!”) notSold print!(“next time I’ll ask 99.9!”) }

26

slide-107
SLIDE 107

PROGRAMMING THE SELLER

c ! selling. c ! “psp”. c ! 100. c "{ sold c?(x).print!(“made “ ^ x ^ “euros!”) notSold print!(“next time I’ll ask 99.9!”) }

Wait for an

  • ption

26

slide-108
SLIDE 108

PROGRAMMING THE SELLER

c ! selling. c ! “psp”. c ! 100. c "{ sold c?(x).print!(“made “ ^ x ^ “euros!”) notSold print!(“next time I’ll ask 99.9!”) }

26

slide-109
SLIDE 109

PROGRAMMING THE SELLER

c ! selling. c ! “psp”. c ! 100. c "{ sold c?(x).print!(“made “ ^ x ^ “euros!”) notSold print!(“next time I’ll ask 99.9!”) }

If the item was sold...

26

slide-110
SLIDE 110

PROGRAMMING THE SELLER

c ! selling. c ! “psp”. c ! 100. c "{ sold c?(x).print!(“made “ ^ x ^ “euros!”) notSold print!(“next time I’ll ask 99.9!”) }

26

slide-111
SLIDE 111

PROGRAMMING THE SELLER

c ! selling. c ! “psp”. c ! 100. c "{ sold c?(x).print!(“made “ ^ x ^ “euros!”) notSold print!(“next time I’ll ask 99.9!”) }

Read the price

26

slide-112
SLIDE 112

PROGRAMMING THE SELLER

c ! selling. c ! “psp”. c ! 100. c "{ sold c?(x).print!(“made “ ^ x ^ “euros!”) notSold print!(“next time I’ll ask 99.9!”) }

26

slide-113
SLIDE 113

PROGRAMMING THE SELLER

c ! selling. c ! “psp”. c ! 100. c "{ sold c?(x).print!(“made “ ^ x ^ “euros!”) notSold print!(“next time I’ll ask 99.9!”) }

If not sold

26

slide-114
SLIDE 114

PROGRAMMING THE SELLER

c ! selling. c ! “psp”. c ! 100. c "{ sold c?(x).print!(“made “ ^ x ^ “euros!”) notSold print!(“next time I’ll ask 99.9!”) }

26

slide-115
SLIDE 115

CHANNEL OPERATIONS

c ! “psp”

Send value

c?(x)

Receive value

c ! selling

Select option

c "{sold:..., notSold:...}

Branch on option

27

slide-116
SLIDE 116

CHANNEL OPERATIONS AND TYPES

c ! selling. c ! “psp”. c ! 100. c "{ sold c ? (x)... notSold ...}

  • Collect all operations on channel c
  • un qualifier omitted on type end; lin omitted on all other

type constructors

28

slide-117
SLIDE 117

CHANNEL OPERATIONS AND TYPES

c ! selling. c ! “psp”. c ! 100. c "{ sold c ? (x)... notSold ...}

{selling: !Item. !Price. &{ sold: ?Price. end, notSold: end}}

  • Collect all operations on channel c
  • un qualifier omitted on type end; lin omitted on all other

type constructors

28

slide-118
SLIDE 118

PROGRAMMING THE BIDDER

c ! register. c ! “Vasco”. c ? (item). c ? (price). if (item = “psp” and price < 100) then c ! buy else c ! notInterested

29

slide-119
SLIDE 119

THE CODE AND THE TYPE FOR THE BIDDER

c ! register. c ! “Vasco”. c ? (item). c ? (price). if (...) then c ! buy else c ! notInterested

  • Collect all operations on channel c
  • Qualifiers omitted on all type constructors as before

30

slide-120
SLIDE 120

THE CODE AND THE TYPE FOR THE BIDDER

c ! register. c ! “Vasco”. c ? (item). c ? (price). if (...) then c ! buy else c ! notInterested

{register: !Name. ?Item. ?Price. {buy: end, notInterested: end}}

  • Collect all operations on channel c
  • Qualifiers omitted on all type constructors as before

30

slide-121
SLIDE 121

THE AUCTIONEER

  • The most sophisticated piece of code
  • More later...

c " { selling -- handle sellers’ requests register -- handle bidders’ requests }

31

slide-122
SLIDE 122

BOOTSTRAPPING

  • How do sellers and bidders start sessions?
  • By requesting such a session on a, the auctioneer’s public,

shared, name:

  • The auctioneer’s public name is a shared channel of type

32

slide-123
SLIDE 123

BOOTSTRAPPING

  • How do sellers and bidders start sessions?
  • By requesting such a session on a, the auctioneer’s public,

shared, name:

  • The auctioneer’s public name is a shared channel of type

Seller = a?(c). c ! selling.c ! “psp”...

32

slide-124
SLIDE 124

BOOTSTRAPPING

  • How do sellers and bidders start sessions?
  • By requesting such a session on a, the auctioneer’s public,

shared, name:

  • The auctioneer’s public name is a shared channel of type

Seller = a?(c). c ! selling.c ! “psp”... Bidder = a?(c). c ! register. c ! “Vasco”...

32

slide-125
SLIDE 125

BOOTSTRAPPING

  • How do sellers and bidders start sessions?
  • By requesting such a session on a, the auctioneer’s public,

shared, name:

  • The auctioneer’s public name is a shared channel of type

Seller = a?(c). c ! selling.c ! “psp”... Bidder = a?(c). c ! register. c ! “Vasco”... S = un?T.S

32

slide-126
SLIDE 126

BOOTSTRAPPING

  • How do auctioneers start sessions?
  • By creating a fresh channel and sending it to clients
  • We shall distinguish the two ends of a channel

Auctioneer = (cc’)( a!c’ | c " {selling ... register ...} | Auctioneer)

33

slide-127
SLIDE 127

BOOTSTRAPPING

  • How do auctioneers start sessions?
  • By creating a fresh channel and sending it to clients
  • We shall distinguish the two ends of a channel

Auctioneer = (cc’)( a!c’ | c " {selling ... register ...} | Auctioneer)

Create the two ends of a channel

33

slide-128
SLIDE 128

BOOTSTRAPPING

  • How do auctioneers start sessions?
  • By creating a fresh channel and sending it to clients
  • We shall distinguish the two ends of a channel

Auctioneer = (cc’)( a!c’ | c " {selling ... register ...} | Auctioneer)

33

slide-129
SLIDE 129

BOOTSTRAPPING

  • How do auctioneers start sessions?
  • By creating a fresh channel and sending it to clients
  • We shall distinguish the two ends of a channel

Auctioneer = (cc’)( a!c’ | c " {selling ... register ...} | Auctioneer)

Send one end to the client

33

slide-130
SLIDE 130

BOOTSTRAPPING

  • How do auctioneers start sessions?
  • By creating a fresh channel and sending it to clients
  • We shall distinguish the two ends of a channel

Auctioneer = (cc’)( a!c’ | c " {selling ... register ...} | Auctioneer)

33

slide-131
SLIDE 131

BOOTSTRAPPING

  • How do auctioneers start sessions?
  • By creating a fresh channel and sending it to clients
  • We shall distinguish the two ends of a channel

Auctioneer = (cc’)( a!c’ | c " {selling ... register ...} | Auctioneer)

Interact on the

  • ther end

33

slide-132
SLIDE 132

BOOTSTRAPPING

  • How do auctioneers start sessions?
  • By creating a fresh channel and sending it to clients
  • We shall distinguish the two ends of a channel

Auctioneer = (cc’)( a!c’ | c " {selling ... register ...} | Auctioneer)

33

slide-133
SLIDE 133

MORE PROCESS CONSTRUCTORS

P | Q

Parallel composition

(cc’)

Channel creation

if v then P else Q

Conditional

34

slide-134
SLIDE 134

REFINING THE AUCTIONEER

  • Concentrate on the selling option; some pseudo-code first
  • Assume a shared repository with operations put, sold, price

c?(item). c?(price). put(item, price) if sold(item) then c ! sold. c!price(item) else c ! notSold

35

slide-135
SLIDE 135

THE SHARED AUCTION DATA REPOSITORY

  • If shared, it must be accessed by a protocol
  • Operation put(item, price) becomes
  • where r is the shared name for the repository

r?(d). d ! put. d!item. d!price

36

slide-136
SLIDE 136

THE SHARED AUCTION DATA REPOSITORY

  • Operations sold(item)/price(item) must be dealt together
  • Sessions c and e are now mixed...
  • ... but the types remain apart. The type of e is

37

slide-137
SLIDE 137

THE SHARED AUCTION DATA REPOSITORY

  • Operations sold(item)/price(item) must be dealt together
  • Sessions c and e are now mixed...
  • ... but the types remain apart. The type of e is

r?(e). e ! wasItSold. e!item. e " {sold c !sold. e?(price). c!price, notSold c !notSold}

37

slide-138
SLIDE 138

THE SHARED AUCTION DATA REPOSITORY

  • Operations sold(item)/price(item) must be dealt together
  • Sessions c and e are now mixed...
  • ... but the types remain apart. The type of e is

r?(e). e ! wasItSold. e!item. e " {sold c !sold. e?(price). c!price, notSold c !notSold} {wasItSold: !Item. &{sold: ?Price.end, notSold: end}}

37

slide-139
SLIDE 139

SESSION DELEGATION

  • Noticed the copy-cat?
  • Why not trust the seller’s channel to the repository? The

repository takes care of replying directly to the client

e " {sold c !sold. e?(price). c!price notSold c !notSold}

38

slide-140
SLIDE 140

SESSION DELEGATION

  • Noticed the copy-cat?
  • Why not trust the seller’s channel to the repository? The

repository takes care of replying directly to the client

e " {sold c !sold. e?(price). c!price notSold c !notSold} r?(e). e!wasItSold. e?(item). e!c

38

slide-141
SLIDE 141

SESSION DELEGATION

  • Noticed the copy-cat?
  • Why not trust the seller’s channel to the repository? The

repository takes care of replying directly to the client

e " {sold c !sold. e?(price). c!price notSold c !notSold} r?(e). e!wasItSold. e?(item). e!c

Sending a channel on a channel

38

slide-142
SLIDE 142

A TYPE FOR THE REPOSITORY

  • The type for the shared channel...
  • ... and that for the session it establishes
  • The seller is not aware of the delegation; it needs not change

its type or its code

39

slide-143
SLIDE 143

A TYPE FOR THE REPOSITORY

  • The type for the shared channel...
  • ... and that for the session it establishes
  • The seller is not aware of the delegation; it needs not change

its type or its code

S = un ?T.S

39

slide-144
SLIDE 144

A TYPE FOR THE REPOSITORY

  • The type for the shared channel...
  • ... and that for the session it establishes
  • The seller is not aware of the delegation; it needs not change

its type or its code

S = un ?T.S T = {put: !Item. !Price. end, wasItSold: !Item. !U. end} U = &{sold: ?Price. end, notSold: end}

39

slide-145
SLIDE 145

A TYPE FOR THE REPOSITORY

  • The type for the shared channel...
  • ... and that for the session it establishes
  • The seller is not aware of the delegation; it needs not change

its type or its code

S = un ?T.S T = {put: !Item. !Price. end, wasItSold: !Item. !U. end} U = &{sold: ?Price. end, notSold: end}

The type of the delegated session

39

slide-146
SLIDE 146

PART II THE THEORY

40

slide-147
SLIDE 147

THE PROGRAMME

  • The language
  • Its typing system and
  • Its operational semantics
  • What is an error?
  • Main result: Typable processes do not reduce to errors

41

slide-148
SLIDE 148

THE PROGRAMME

  • The language
  • Its typing system and
  • Its operational semantics
  • What is an error?
  • Main result: Typable processes do not reduce to errors

Very much standard!

41

slide-149
SLIDE 149

1. THE LANGUAGE

42

slide-150
SLIDE 150

CHANNEL CREATION

  • Variables come in pairs, called co-variables
  • Each represents one end of a communication channel
  • Interacting threads do not share variables for communication;

instead, each thread owns its variable

  • This mechanism allows a precise control of resources via a

linear type system

43

slide-151
SLIDE 151

THE SYNTAX OF PROCESSES, TO START WITH

P ::= Processes: x v.P

  • utput

x(x).P input P | P parallel composition

if v then P else P

conditional inaction

(νxx)P

scope restriction v ::= Values: x variable

true | false

boolean values

44

slide-152
SLIDE 152

2. TYPING SYSTEM

45

slide-153
SLIDE 153

LINEAR AND UNRESTRICTED TYPES

  • Lin (linear) qualified types describe variables that occur in

exactly one thread

  • Un (unrestricted, shared) qualifier indicates a value that can
  • ccur in multiple threads
  • Type lin ! (lin bool). un end represents a channel-end that

can be used once to output a boolean value (that can be used

  • nce) and then behaves as shared channel on which no

further operation is possible

46

slide-154
SLIDE 154

THE SYNTAX OF TYPES

q ::= Qualifiers:

lin

linear

un

unrestricted p ::= Pretypes:

bool

booleans

end

termination ?T.T receive !T.T send T ::= Types: q p qualified pretype Γ ::= Contexts: ∅ empty context Γ, x: T assumption

47

slide-155
SLIDE 155

EXAMPLE: VALID AND INVALID PROCESSES

  • x is a variable of an arbitrarily qualified type
  • a is a variable of an unrestricted type, and
  • c a variable of a linear type

x true.x(y) a true | a true | a false c true | c false Omit the trailing 0

48

slide-156
SLIDE 156

DUALITY

q ?T.U = q !T.U q !T.U = q ?T.U q end = q end x1 true | x2(z) x1 true.x1(w) | x2(z).x2 false x1 true | x2 false x1 true.x1(w) | x2(z).x2(t) and are two co-variables x1 x2 No rule for bool

49

slide-157
SLIDE 157

CONTEXT SPLITTING

  • An operation central to linear typing systems
  • When type checking processes with two sub-processes we

pass the unrestricted part of the context to both processes, while splitting the linear part in two and passing a different part to each process

∅ · ∅ = ∅ Γ = Γ1 · Γ2

un(T)

Γ, x: T = (Γ1, x: T) · (Γ2, x: T) Γ = Γ1 · Γ2

lin(T)

Γ, x: T = (Γ1, x: T) · Γ2 Γ = Γ1 · Γ2

lin(T)

Γ, x: T = Γ1 · (Γ2, x: T)

50

slide-158
SLIDE 158

TYPE SYSTEM: INVARIANTS

  • Linear channels occur in exactly one thread
  • Co-variables have dual types

51

slide-159
SLIDE 159

TYPING RULES FOR VALUES

  • The rules make sure that linear variables are not discarded

without being used

  • The base cases of the type system check that there is no linear

variable in the context

un(Γ)

Γ ⊢ false: bool

un(Γ1, Γ2)

Γ1, x: T, Γ2 ⊢ x: T

52

slide-160
SLIDE 160

TYPING RULES FOR PROCESSES (1/3)

  • The base case checks that there is no linear variable in the

context

  • Parallel composition crucially takes advantage of context

splitting

un(Γ)

Γ ⊢ 0 Γ1 ⊢ P Γ2 ⊢ Q Γ1 · Γ2 ⊢ P | Q

53

slide-161
SLIDE 161

TYPING RULES FOR PROCESSES (2/3)

  • No context splitting for the two branches in the conditional
  • The rule for scope restriction captures the essence of co-

variables: they must have dual types

Γ1 ⊢ v: q bool Γ2 ⊢ P Γ2 ⊢ Q Γ1 · Γ2 ⊢ if v then P else Q Γ, x: T, y: T ⊢ P Γ ⊢ (νxy)P

54

slide-162
SLIDE 162

TYPING RULES FOR PROCESSES (3/3)

  • The rule for input splits the context into two parts: one to

type check x, the other to type check continuation P

  • If x: q?T.U in x(y).P then we use y:T to type check P
  • x(y).P uses x at type q?T.U, whereas P may use the same

variable this time at type U

Γ1 ⊢ x: q ?T.U

(Γ2, y: T) · x: U ⊢ P

Γ1 · Γ2 ⊢ x(y).P Γ1 ⊢ x: q !T.U Γ2 ⊢ v: T Γ3 · x: U ⊢ P Γ1 · Γ2 · Γ3 ⊢ x v.P

55

slide-163
SLIDE 163

TYPING RULES FOR PROCESSES (SUMMARY)

un(Γ)

Γ ⊢ 0 Γ1 ⊢ P Γ2 ⊢ Q Γ1 · Γ2 ⊢ P | Q Γ1 ⊢ v: q bool Γ2 ⊢ P Γ2 ⊢ Q Γ1 · Γ2 ⊢ if v then P else Q Γ, x1 : T, x2 : T ⊢ P Γ ⊢ (νx1x2)P Γ1 ⊢ x: q ?T.U

(Γ2, y: T) · x: U ⊢ P

Γ1 · Γ2 ⊢ x(y).P Γ1 ⊢ x: q !T.U Γ2 ⊢ v: T Γ3 · x: U ⊢ P Γ1 · Γ2 · Γ3 ⊢ x v.P

56

slide-164
SLIDE 164

A SIMPLE SESSION

Unrestricted environment Unrestricted qualifiers omitted x: T ⊢ x: T ∅ ⊢ true: bool x: T ′ ⊢ x: T ′ x: end, y: bool ⊢ 0 x: T ′ =?bool.end ⊢ x(y).0 x: T = lin!bool.?bool.end ⊢ x true.x(y).0

57

slide-165
SLIDE 165

LINEAR VALUES ARE CONSUMED

Not unrestricted Process not typable

x: T ⊢ x: T ∅ ⊢ true: bool x: T ′ ⊢ x: T ′ x: end, y: lin bool ⊢ 0 x: T ′ =?(lin bool).end ⊢ x(y).0 x: T = lin!bool.?(lin bool).end ⊢ x true.x(y).0

58

slide-166
SLIDE 166

A LANGUAGE OF LINEAR CHANNELS ONLY

Process not typable; to be fixed! Context splitting not defined Parallel composition

Γ ⊢ x: !(bool).end Γ ⊢ true: bool Γ · (x: end) ⊢ 0 Γ ⊢ x true Γ ⊢ x true Γ = x: !(bool).end ⊢ x true | x true

59

slide-167
SLIDE 167

3. OPERATION SEMANTICS

60

slide-168
SLIDE 168

STRUCTURAL CONGRUNECE

  • Factor out a on processes allowing the syntactic

rearrangement of these

  • Contribute for a more concise presentation of the reduction

relation

P | Q ≡ Q | P (P | Q) | R ≡ P | (Q | R) P | 0 ≡ P (νxy)P | Q ≡ (νxy)(P | Q) (νxy)0 ≡ 0 (νwz)(νxy)P ≡ (νxy)(νwz)P

61

slide-169
SLIDE 169

REDUCTION

(νxy)(x v.P | y(z).Q | R) → (νxy)(P | Q[v/z] | R)

if true then P else Q → P if false then P else Q → Q

P → Q (νxy)P → (νxy)Q P → Q P | R → Q | R P ≡ P ′ P ′ → Q′ Q′ ≡ Q P → Q

62

slide-170
SLIDE 170

WHAT CAN GO WRONG?

  • An obvious case: in a conditional process the value in the

condition is neither true nor false

  • More interesting:
  • Notice: no mention of types or lin/un channel nature

a true | a(z) (νx1x2)(x1 true | x2 true) (νx1x2)(x1(z) | x2(w))

63

slide-171
SLIDE 171

WHAT CAN GO WRONG?

  • An obvious case: in a conditional process the value in the

condition is neither true nor false

  • More interesting:
  • Notice: no mention of types or lin/un channel nature

a true | a(z) (νx1x2)(x1 true | x2 true) (νx1x2)(x1(z) | x2(w)) Different communication patterns on the same channel end

63

slide-172
SLIDE 172

WHAT CAN GO WRONG?

  • An obvious case: in a conditional process the value in the

condition is neither true nor false

  • More interesting:
  • Notice: no mention of types or lin/un channel nature

a true | a(z) (νx1x2)(x1 true | x2 true) (νx1x2)(x1(z) | x2(w))

63

slide-173
SLIDE 173

WHAT CAN GO WRONG?

  • An obvious case: in a conditional process the value in the

condition is neither true nor false

  • More interesting:
  • Notice: no mention of types or lin/un channel nature

a true | a(z) (νx1x2)(x1 true | x2 true) (νx1x2)(x1(z) | x2(w)) Channels ends with incompatible communication patterns

63

slide-174
SLIDE 174

WHAT CAN GO WRONG?

  • An obvious case: in a conditional process the value in the

condition is neither true nor false

  • More interesting:
  • Notice: no mention of types or lin/un channel nature

a true | a(z) (νx1x2)(x1 true | x2 true) (νx1x2)(x1(z) | x2(w))

63

slide-175
SLIDE 175

WELL TYPED PROGRAMS DO NOT GO WRONG

  • Outline of the proof
  • 1. Type preservation
  • 2. Type safety
  • 3. Compose and done! (details in the book)

If Γ ⊢ P and P → Q then Γ ⊢ Q If ⊢ P then P is well formed

64

slide-176
SLIDE 176

4. RECURSIVE TYPES

65

slide-177
SLIDE 177

RECURSIVE TYPES

  • Context splitting not defined...
  • ... unless there is type T such that
  • Use a finite notation for the solution of the equation

µa.!bool.a !bool.T = T

x: !bool.T ⊢ x: !bool.T x: !bool.T ⊢ true: bool (x: !bool.T) · (x: end) ⊢ 0 x: !bool.T ⊢ x true

66

slide-178
SLIDE 178
  • Shared output channels are of types a.!T.a which we

abbreviate to *!T

  • Unfold/fold recursive types as needed: equi-recursive notion of

types

TYPES FOR SHARED CHANNELS

∗!bool = !bool.∗!bool Γ ⊢ x: ∗!bool Γ ⊢ true: bool Γ · (x: ∗!bool) ⊢ 0 Γ = x: !bool.∗!bool ⊢ x true

67

slide-179
SLIDE 179

EXAMPLE _ TUPLE PASSING ON SHARED CHANNELS

  • If x is is shared then there is a risk of interference
  • Use the standard encoding...
  • ... which is typable

x u, v.P = x u.x v.P

  • k if x is

linear x1 u, v.P = (νy1y2)x1 y2.y1 u.y1 v.P x2(w, t).P = x2(z).z(w).z(t).P x1 : ∗!(lin?T.lin?U) x2 : ∗?(lin!T.lin!U)

68

slide-180
SLIDE 180

LINEAR CHANNELS THAT BECOME UNRESTRICTED

  • Suppose that
  • Then

x1 true.(x1(y) | x1(z)) | x2(x).(x2 true | x2 false | x2 true) x1 : lin!bool.∗?bool x2 : lin?bool.∗!bool

69

slide-181
SLIDE 181

5. REPLICATION

70

slide-182
SLIDE 182

UNBOUNDED BEHAVIOR

  • Up until now our language is strongly normalizing
  • Providing for unbounded behavior
  • Recursion (as in the auctioneer example)
  • Replication
  • Replication is conceptually simpler; we go for it

71

slide-183
SLIDE 183

SYNTAX AND REDUCTION

  • New syntax
  • New reduction rule

P ::= . . . Processes: ∗ x(x).P replication (νxy)(x v.P | ∗y(z).Q | R) → (νxy)(P | Q[v/z] | ∗y(z).Q | R) (νxy)(x v.P | y(z).Q | R) → (νxy)(P | Q[v/z] | R) The replicated process survives reduction

72

slide-184
SLIDE 184

TYPING

Γ ⊢ P

un(Γ)

Γ ⊢ ∗P

73

slide-185
SLIDE 185

TYPING

P can be used multiple times Γ ⊢ P

un(Γ)

Γ ⊢ ∗P

73

slide-186
SLIDE 186

TYPING

Γ ⊢ P

un(Γ)

Γ ⊢ ∗P

73

slide-187
SLIDE 187

“PROCEDURES”

  • A procedure that sends a boolean value on a fixed channel c
  • c cannot be linear for the body of the procedure must be un
  • What if we pass c as parameter?
  • The type system controls the linearity of the arguments
  • Linear values in procedures must be passed as parameters

p2 : ∗?end, c: lin!bool ⊢ ∗ p2(z).c true ∗p2(z).c true | p1 x | p1 x → → ∗p2(z).c true | c true | c true p2 : ?(lin!bool) ⊢ ∗ p2(z).z true . . . , p2 : ?(lin!bool) ⊢ ∗ p2(z).z true | p1 c | p1 c

74

slide-188
SLIDE 188

6. CHOICE

75

slide-189
SLIDE 189

CHOICE _ SYNTAX

P ::= . . . Processes: x ⊳ l.P selection x ⊲ {li : Pi}i∈I branching p ::= . . . Pretypes: ⊕{li : Ti}i∈I select &{li : Ti}i∈I branch

76

slide-190
SLIDE 190

CHOICE _ REDUCTION

j ∈ I (νxy)(x ⊳ lj.P | y ⊲ {li : Qi}i∈I | R) → (νxy)(P | Qj | R)

77

slide-191
SLIDE 191

CHOICE _ TYPING

  • Duality
  • Typing

q ⊕{li : Ti}i∈I = q &{li : Ti}i∈I q &{li : Ti}i∈I = q ⊕ {li : Ti}i∈I

Γ2 ⊢ x: q ⊕{li : Ti}i∈I Γ2 · x: Tj ⊢ P j ∈ I Γ1 · Γ2 ⊢ x ⊳ lj.P Γ1 ⊢ x: q &{li : Ti}i∈I Γ2 · x: Ti ⊢ Pi ∀i ∈ I Γ1 · Γ2 ⊢ x ⊲ {li : Pi}i∈I

78

slide-192
SLIDE 192

7. SUBTYPING

79

slide-193
SLIDE 193

MOTIVATION

  • Subtyping brings extra flexibility to our type system
  • The insistence that arguments in output processes exactly

match input parameters in corresponding receivers leads to the rejection of programs that will never go wrong when executed

  • We have seen examples in the first part

80

slide-194
SLIDE 194

INGREDIENTS

  • We need
  • A notion of subtyping. T <: U means any value of type T can

be safely used in a context where U is expected

  • A rule to incorporate subtyping in the type system

Γ ⊢ v: T T <: U Γ ⊢ v: U

81

slide-195
SLIDE 195

FINITE SUBTYPING _ CHOICE

  • The auctioneer can forget options in order to address sellers
  • r bidders
  • Conversely sellers may call more options on the auctioneer

(so as to behave as bidders as well)

I ⊆ J Ti <: Ui ∀i ∈ I &{li : Ti}i∈I <: &{lj : Uj}j∈J I ⊇ J Tj <: Uj ∀j ∈ J ⊕{li : Ti}i∈I <: ⊕{lj : Uj}j∈J

82

slide-196
SLIDE 196

FINITE SUBTYPING _ I/O

  • Input is co-variant; output is contra-variant
  • In summary:
  • Input operations (?, &) are co-variant; output operations (!,

) contra-variant

  • Continuations are always co-variant
  • See book for subtyping recursive types

T ′ <: T U <: U ′ !T.U <: !T ′.U ′ T <: T ′ U <: U ′ ?T.U <: ?T ′.U ′

83

slide-197
SLIDE 197

8. CONCLUSION

84

slide-198
SLIDE 198

ALGORITHMIC TYPE CHECKING

  • The typing rules cannot be implemented directly for two main
  • reasons. Difficulties
  • Implementing the non-deterministic splitting operation
  • Guessing the types for nu-bound variables

See book!

85

slide-199
SLIDE 199

WE INTRODUCED...

  • A (type) language to describe (the protocol part of) services
  • A (programming) language to program protocols
  • A decidable type checking system that makes sure that “well

typed programs do not go wrong”

86

slide-200
SLIDE 200

LOOKING FOR RESEARCH TOPICS?

  • Programs can easily deadlock
  • Identify conditions / refine the type system so as to ensure

progress

  • Context splitting for both parallel and sequential composition

x1 true.y1 false | y2(x).x2(w) Γ1 ⊢ x: q ?T.U (Γ2, y: T) · x: U ⊢ P Γ1 · Γ2 ⊢ x(y).P Sequential Parallel

87