1. 1 IOA: Distributed Algorithms  Distributed Programs Nancy Lynch PODC 2000 Collaborators: Steve Garland, Josh Tauber, Anna Chefter, Antonio Ramirez, Michael Tsai, Mandana Vaziri, Tina Nolte I O A

2. 2 What we want to do: See how abstract I/O automaton models of distributed algorithms and services could be used in producing and maintaining actual distributed programs.

3. 3 Why use models in programming? Models let you: –Build complex things and get them right –Change things and understand the consequences –Explain clearly how things work Other engineering disciplines use them

4. 4 But why I/O automaton models? Simple mathematical basis for describing structure + behavior of systems of interacting components Already used for: –Distributed algorithms, impossibility results –System case studies: Group communication services (Orca, Transis, Ensemble,…) Communication protocols (TCP, T/TCP,…) Hybrid (continuous/discrete) systems (TCAS,…)

5. 5 I/O automata [Lynch, Tuttle 87] Nondeterministic state machines Infinite state Input/output/internal actions Transitions, executions, traces Supports modularity: –Composition –Levels of abstraction Mathematical model, language-independent

6. 6 Model service specs, distributed algorithms Refine, from high level global service spec to detailed distributed algorithm: Make models as nondeterministic as possible Prove correctness, using invariants, simulation relations, composition How I/O automata are used

7. 7 TO Broadcast Service Spec [Fekete, Lynch, Shvartsman, PODC 97] Signature: input: broadcast(a,p) output: receive(a,p,q) internal: order(a,p) State: queue, sequence of (a,p), initially empty for each p: pending[p], sequence of a, initially empty next[p], positive integer, initially 1 TO

8. 8 TO Broadcast Transitions : broadcast(a,p) Effect: append a to pending[p] order(a,p) Precondition: a is head of pending[p] Effect: remove head of pending[p]; append (a,p) to queue receive(a,p,q) Precondition: queue[next[q]] = (a,p) Effect: next[q] := next[q] + 1

9. 9 IOA Language [Garland, Lynch 97] Programming/specification language for defining I/O automata Similar to pseudocode Explicitly describes : –Signature, structured state, precondition/effects –Nondeterministic choice, composition, invariants, levels of abstraction Declarative + imperative For proofs For simulation, code generation I O A

10. 10 IOA Tools Front end: Parser, static checker, intermediate Java representation [Garland, Ramirez] Support for: –Composing models [Chefter 98] [Garland, Lynch] –Refining models, from global specification to low-level distributed algorithm model: Step correspondence [Ramirez 00]

11. 11 IOA Tools Prototype code generator, for generating distributed code from low-level distributed algorithm models [Tauber, Tsai] Validation tools: –Simulator [Chefter 98] [Ramirez 00] Paired simulation: –Theorem-prover interfaces: PVS [Devillers], Isabelle? LP? NuPRL? [Nolte] –Automatic?

12. 12 Modeling Projects Distributed spanning tree algorithms [Luhrs, Nolte] Distributed replicated data management algorithms: Lamport state machines; Attiya, Bar-Noy, Dolev, … [Dean, Karlovich, Rosen] Future: –Practical communication protocols, services –Interacting Java objects

13. 13 TLA and IOA TLA and IOA both: –Use precondition/effect style –Support nondeterministic choice –Support similar kinds of assertional proofs TLA: –Is typeless –Is declarative –Has good automatic tools IOA: –Uses Larch Shared Language data types –Declarative + imperative –Emphasizes system decomposition