SLIDE 1
Programming and Proving with Distributed Protocols
{P} c {Q}
`
James R. Wilcox Zach Tatlock Ilya Sergey
http://distributedcomponents.net
Disel: Distributed Separation Logic
Distributed Systems
` http://distributedcomponents.net Ilya Sergey James R. Wilcox - - PowerPoint PPT Presentation
` http://distributedcomponents.net Ilya Sergey James R. Wilcox - - PowerPoint PPT Presentation
Programming and Proving with Distributed Protocols Disel: Distributed Separation Logic { P } c { Q } ` http://distributedcomponents.net Ilya Sergey James R. Wilcox Zach Tatlock Distributed Systems Distributed Infrastructure Distributed
SLIDE 2
SLIDE 3
Distributed Infrastructure
SLIDE 4
Distributed Applications
SLIDE 5
Verified Distributed Systems
SLIDE 6
Verified Distributed Infrastructure
SLIDE 7
Verified Distributed Infrastructure
- Cert
Veri- Iron Wow
SLIDE 8
Verified Distributed Applications
SLIDE 9
Verified Distributed Applications
- Cert
Veri- Iron Wow
SLIDE 10
Verified Distributed Applications
- Cert
Veri- Iron Wow
Challenging to verify apps in terms of infra. starting from scratch is unacceptable Indicates deeper problems with composition
- ne node’s client is another’s server!
SLIDE 11
Verified Distributed Applications
- Cert
Veri- Iron Wow
Client reasoning Invariants Separation Challenges
SLIDE 12
Verified Distributed Applications
- Cert
Veri- Iron Wow
Client reasoning Invariants Separation Challenges Protocols rule rule/Hooks Solutions
WithInv Frame
`{P} c {Q}
Disel:
SLIDE 13
Outline
Protocols and running example Logical mechanisms programming with protocols invariants framing and hooks
`{P} c {Q}
Implementation and future work
SLIDE 14
Cloud Compute
S C
SLIDE 15
Cloud Compute
S C
21
SLIDE 16
Cloud Compute
SLIDE 17
Cloud Compute
SLIDE 18
Cloud Compute
while true: (from, n) <- recv Req send Resp(n, factors(n)) to from
: Server
SLIDE 19
Cloud Compute
while true: (from, n) <- recv Req send Resp(n, factors(n)) to from
: Server
Traditional specification: messages from server have correct factors Proved by finding an invariant of the system
SLIDE 20
Cloud Compute: Server
SLIDE 21
Cloud Compute: Client
SLIDE 22
Cloud Compute: Client
send Req(21) to server (_, ans) <- recv Resp assert ans == {3, 7}
SLIDE 23
Cloud Compute: Client
send Req(21) to server (_, ans) <- recv Resp assert ans == {3, 7}
Start over with clients in system?
SLIDE 24
Cloud Compute: Client
send Req(21) to server (_, ans) <- recv Resp assert ans == {3, 7}
Start over with clients in system? In Disel: use protocol to describe client interface
SLIDE 25
Protocols
SLIDE 26
Protocols
SLIDE 27
Protocols
A protocol is an interface among nodes
SLIDE 28
Protocols
A protocol is an interface among nodes Enables compositional verification
SLIDE 29
Cloud Compute Protocol
Messages:
SLIDE 30
Cloud Compute Protocol
State: Messages:
SLIDE 31
Cloud Compute Protocol
State: Transitions: Messages:
SLIDE 32
Cloud Compute Protocol
State: Transitions: Messages: Sends: precondition and effect
SLIDE 33
Cloud Compute Protocol
State: Transitions: Messages: Sends: precondition and effect Receives: effect
SLIDE 34
Cloud Compute Protocol
State: Transitions: Messages: Sends: Receives:
SLIDE 35
Cloud Compute Protocol
State: Transitions: Messages: Req(n) | Resp(n,s) Sends: Receives:
SLIDE 36
Cloud Compute Protocol
State: Transitions:
- utstanding: Set<Msg>
Messages: Req(n) | Resp(n,s) Sends: Receives:
SLIDE 37
Cloud Compute Protocol
Req
State: Transitions:
- utstanding: Set<Msg>
Messages: Req(n) | Resp(n,s) Sends: Receives:
Resp Req Resp
SLIDE 38
Cloud Compute
S C
Req(21)
Effect: none
Send Req(n)
Precondition: none
SLIDE 39
Cloud Compute
S C
Req(21)
Effect:
Receive Req(n)
add (from, n) to out
{ }
(C,21)
SLIDE 40
Cloud Compute
S C
Resp({3,7})
Effect: removes (n,to) from out
Send Resp(n,l)
Requires: l == factors(n) (n,to) in out
{ }
SLIDE 41
Cloud Compute
S C
Resp({3,7})
Recv Resp(n,l)
Effect: none
{ }
SLIDE 42
Cloud Compute Protocol
Req
State: Transitions:
- utstanding: Set<Msg>
Messages: Req(n) | Resp(n,s) Sends: Receives:
Resp Req Resp
SLIDE 43
Outline
Protocols and running example Logical mechanisms programming with protocols invariants framing and hooks
`{P} c {Q}
Implementation and future work
SLIDE 44
Cloud Compute
while true: (from, n) <- recv Req send Resp(n, factors(n)) to from
: Server
SLIDE 45
Cloud Compute
while true: (from, n) <- recv Req send Resp(n, factors(n)) to from
: Server
Precondition on send requires correct factors
SLIDE 46
Cloud Compute: Server
Precondition on send requires correct factors
`
{
}
t
sent ( )
m h
,
send m to h
{Pre }
t
while true: (from, n) <- recv Req send Resp(n, factors(n)) to from
SLIDE 47
Cloud Compute: Server
Precondition on send requires correct factors
`
send m to h
t
{
}
t
sent ( )
m h
,
{Pre }
t
while true: (from, n) <- recv Req send Resp(n, factors(n)) to from
SLIDE 48
Cloud Compute: Server
Precondition on send requires correct factors
`
send m to h
t t ∈
{
}
t
sent ( )
m h
,
{Pre }
t
while true: (from, n) <- recv Req send Resp(n, factors(n)) to from
SLIDE 49
Cloud Compute: Server
Precondition on send requires correct factors
`
send m to h
t t ∈
{
}
t
sent ( )
m h
,
{Pre }
t
while true: (from, n) <- recv Req send Resp(n, factors(n)) to from
SLIDE 50
Cloud Compute: Server
Precondition on send requires correct factors
`
send m to h
t t ∈
{
}
t
sent ( )
m h
,
{Pre }
t
while true: (from, n) <- recv Req send Resp(n, factors(n)) to from
SLIDE 51
Cloud Compute: Client
send Req(21) to server (_, ans) <- recv Resp assert ans == {3, 7}
SLIDE 52
Cloud Compute: Client
send Req(21) to server (_, ans) <- recv Resp assert ans == {3, 7}
recv doesn’t ensure correct factors
SLIDE 53
Cloud Compute: Client
send Req(21) to server (_, ans) <- recv Resp assert ans == {3, 7}
recv doesn’t ensure correct factors
SLIDE 54
Cloud Compute: Client
t ∈
`
recv
t
{>}
m {recvd( )} m
send Req(21) to server (_, ans) <- recv Resp assert ans == {3, 7}
recv doesn’t ensure correct factors
SLIDE 55
Protocol Invariants
`{P} c {Q}
`{P ∧ I} c {Q ∧ I}
I inductive
SLIDE 56
Protocol Invariants
`{P} c {Q}
`{P ∧ I} c {Q ∧ I}
I inductive
Protocol where every state satisfies I
SLIDE 57
Cloud Compute: Client
t ∈
Now recv ensures correct factors
`
recv
t
{>}
m {recvd( )} m
send Req(21) to server (_, ans) <- recv Resp assert ans == {3, 7}
SLIDE 58
Cloud Compute: More Clients
send Req(21) to server1 send Req(35) to server2 (_, ans1) <- recv Resp (_, ans2) <- recv Resp assert ans1 ans2 == {3, 5, 7}
∪
SLIDE 59
Cloud Compute: More Clients
send Req(21) to server1 send Req(35) to server2 (_, ans1) <- recv Resp (_, ans2) <- recv Resp assert ans1 ans2 == {3, 5, 7}
∪
Same protocol enables verification
SLIDE 60
Frame rule
`{P} c {Q}
R stable
` {P R} c {Q R}
∗ ∗
SLIDE 61
Frame rule
`{P} c {Q}
R stable
` {P R} c {Q R}
∗ ∗
Reuse invariants from component protocols
SLIDE 62
Frame rule
`{P} c {Q}
R stable
` {P R} c {Q R}
∗ ∗
Reuse invariants from component protocols independent protocols
SLIDE 63
`{P} c {Q}
R stable
` {P R} c {Q R}
∗ ∗
Frame rule: Hooks
SLIDE 64
`{P} c {Q}
R stable
` {P R} c {Q R}
∗ ∗
Frame rule: Hooks
Allows one protocol to restrict another
SLIDE 65
Outline
Protocols and running example Logical mechanisms programming with protocols invariants framing and hooks
`{P} c {Q}
Implementation and future work
SLIDE 66
Implementation
Executable via extraction to OCaml Shallowly embedded in Coq
with full power of functional programming via trusted shim to implement semantics
Case study: two-phase commit
exercises all features of the logic
SLIDE 67
Related and Future Work
Adding other effects
e.g. mutable heap, threads, failure…
Concurrent separation logics
Iris, FCSL, CAP, …
SLIDE 68
Composition: A way to make proofs harder
SLIDE 69
Composition: A way to make proofs harder
“In 1997, the unfortunate reality is that engineers rarely specify and reason formally about the systems they build. It seems unlikely that reasoning about the composition of open-system specifications will be a practical concern within the next 15 years.”
SLIDE 70
Verified Distributed Applications
- Cert
Veri- Iron Wow
Client reasoning Invariants Separation Challenges Protocols rule rule/Hooks Solutions
WithInv Frame
`{P} c {Q}
Disel: