1. 01/05/2015 Agay Spring School, March'02 Mobility 1 : the Pi Calculus Cédric Fournet Microsoft Research Cambridge

2. References Communicating and Mobile Systems: The Pi-Calculus, Robin Milner, Cambridge University Press, 1999 The Pi-Calculus: a Theory of Mobile Processes Davide Sangiorgi and David Walker, Cambridge University Press, 2001 See also http://research.microsoft.com/~fournet/http://research.microsoft.com/~fournet/

3. Contents 1. Mobile Names: the Pi Calculus Mini CCS basics: syntax, semantics,… Some equivalences Name Mobility in the Pi Calculus Process Mobility Applications & Alternatives 2. Mobile Ambients [Luca] 3. Security Protocols in the Applied Pi Calculus [Martin] 4. Mobility and Security [Cedric] 5. Spatial Logics [Luca]

4. Communicating Systems ? Two related questions: What is a function? Sequential machines Models for computation: lambda, PCF, abstract machines What is a process? Coffee Machines, Xboxes, distributed systems. Models for interaction: CCS/CSP [80s], Pi [90s] How to model concurrent behaviours? How to describe processes in a compositional manner? When are two processes equivalent? Divergence is not necessarily bad. Operational, rather than denotational.

5. Why Using a Calculus ? A calculus, rather than a purely descriptive model “Calculate” = reason on processes in a systematic manner using equations. State and prove correctness properties. Reuse basic tools, such as observational equivalences and proof techniques. Two different viewpoints: Specification language: Describe and validate concurrent protocols. Core programming language: Principles for language design S emantics for concurrent programs Executable spec, with implementation constraints.

6. Asynchronous Programming Distributed programs Network of interconnected devices Hard to write: asynchronous, uncertain, open environment Harder to understand & relate to a specification Awkward to test & debug Not much programming-language support Traditional (low-level, sequential) languages Various design patterns Libraries for concurrency, synchronisation, distribution, communications,… Distributed programming biased in this setting: e.g. RPC/RMI rather than asynchronous events What are good abstractions for asynchronous programming?

7. Mobile Programming The distributed configuration of the system evolves as part of the computation. Example: mobile agents More general, quite common, usually not explicit Mobility? Dynamically export references to local resources (name mobility) Dynamically retrieve, link, and execute some remote library (code mobility) Move active parts of the computation from one machine to another (object mobility, thread mobility, strong mobility,…) What are good abstractions for mobile programming?

8. 01/05/2015 Agay Spring School, March'02 Mini CCS A Calculus of Communicating Systems [Milner,80]

9. Mini CCS

10. Examples Reductions Constants: globally-defined, recursive Internal choice (encoding)

11. Contexts A context is a process with a placeholder. An evaluation context is a context with an active placeholder.

12. Reduction Semantics Communication: Handshake Reduction is defined “up to structural rearrangements” (chemical-style semantics)

13. Structural equivalence Structural equivalence ´ gathers all syntactic rearrangements of running processes that preserve the scopes is complicated, but has no real computational contents can be oriented, to get partial normal forms

14. 01/05/2015 Agay Spring School, March'02 Contextual Equivalences How to calculate ?

15. Observational Equivalences We may want to check that our processes have some observable properties. So far, we described the calculus; we must be able to calculate too! Which equivalence? An embarrassing choice. Numerous notions of equivalence for process calculi. Trade-off between expressiveness and proof techniques. For a given equivalence, many different formulations. We motivate and compare three common equivalences (first for mini CCS)

16. Which equivalence? The ideal process equivalence: 1. When two processes are equivalent, they have the same properties. In every system, one can replace one with the other without affecting the system in any visible way (sound). 2. Conversely, when two processes are not equivalent, there is a system where replacing one with the other makes some visible change (complete). 3. There are simple, effective techniques for proving equivalences (simple) 4. The equivalence has a rich set of identities, so that we can “compute” on processes (expressive)

17. May Testing May testing equivalence is the equivalence of processes that have the same safety properties: observed in a finite number of interactions, according to the communication rule, without termination, timing, or liveness properties. We need to define a notion of test, or experiment. We reuse our calculus: A test is just a process (actually, a context) By convention, the test “succeeds” when this testing process sends a message on a given channel.

18. What is observable? Our “test harnesses” range over all evaluation contexts in CCS. Basic observation predicates detect (any) output on a given name:

19. May Testing Equivalence The definition of may testing naturally follows: This definition is “robust”: we can change the definitions of observations and contexts, and still obtain the same equivalences for CCS processes.

20. May Testing Equivalence Observing outputs as a whole (on any name) Observing inputs May-testing for both inputs and outputs yields the same equivalence.

21. May Testing Equivalence Some equations: Structural equivalence (by definition) Internal communication is invisible: Concurrent communication is invisible Divergence is invisible Practical proof techniques? Not quite May testing is not too fine: good counter-examples May testing is sometimes too coarse.

22. Deadlocks? May testing is sometimes too coarse. Consider internal choices, defined as We always have i.e. may testing does not detect potential deadlocks.

23. Fair Testing We can use a more sophisticated test: fair testing detects whether a process always retain the possibility of emitting on a

24. Fair Testing Ce

25. Fair Testing Equivalence We have

26. Fair Testing Useful equations Practical proof techniques? Not at all… Some fairness (detects deadlocks, but no livelocks)

27. Fair Testing Useful equations Practical proof techniques? Not at all… Some fairness (detects deadlocks, but no livelocks) Relation with may testing? We can use contexts such that

28. Getting Organized Some useful properties for expressiveness: context closure and basic observables.

29. Equivalence Requirements For instance, is the largest relation that meets conditions (C), (X), and (  ). This is a convenient way to organize equivalences Equivalences defined as largest relations that meet some (monotonic) properties have co-inductive proof techniques.

30. Towards Co-inductive Proofs  To prove P  Q for some given processes, RR 1. Choose any relation R such that P R Q R  2. Prove that R meets all the requirements in the definition of equivalence  R µ  R 3. This establishes R µ , hence P R Q This is a good starting point for proofs: - We can choose more convenient requirements that define the same equivalence relation R - We can add requirements that make R simpler

31. A key property for proofs The (weak) simulation property [Park, Milner]: Simulation requires a direct lock-step correspondence of reductions between related processes. (This is not obviously observable.)

32. Barbed Congruence Barbed Congruence  is the largest symmetric relation that meets conditions (C), (  ), and (S) Finer than may testing (by definition) and also finer than fair testing (proof) Much easier to establish For example,

33. Barbed Congruence (redefined) Barbed Congruence is also the largest symmetric relation that meets the three conditions:

34. A hierarchy of equivalences It is often convenient to combine several equivalences to study the properties of processes. Lemmas and proofs use finer equivalences.

35. 01/05/2015 Agay Spring School, March'02 Using labels instead of contexts Explicit actions, finer equivalences, simpler proofs.

36. Labelled Transition System

37. Labels vs Reductions Reduction semantics are easier to grasp Labelled semantics make interaction with the environment more explicit Labelled semantics are technically simpler (structural/labelled case analysis vs induction on contexts) It is useful to have both semantics, especially when they “coincide”

38. Labelled Bisimilarity Labelled (weak) simulation property: A relation R is a labelled bisimulation when R and R -1 meet (S) and (S  ). Labelled bisimilarity is the largest labelled bisimulation

39. Labelled Bisimilarity (2) Labelled bisimilarity is a congruence Proof (sketch) For prefix: { ( .P, .Q) | P ¼ Q } [ ¼ Similarly for parallel composition, for restriction Labelled bisimilarity = Barbed congruence Proof (sketch) Hence, labelled bisimulation (and its variants) yields an effective proof technique for contextual equivalences

40. 01/05/2015 Agay Spring School, March'02 Mobility ? A Calculus of Mobile Processes [Milner Parrow Walker,92]

41. Value-Passing CCS Interaction on free channels, as before Convenient, but not essential: could use more channels

42. The Pi Calculus Channel names can be communicated Communication becomes dynamic

43. Reduction Semantics (as before) Communication Structural equivalence

44. Name Mobility “The dynamic creation of new links between active processes” [Milner] At a suitable level of abstraction, the location of a process is determined by its links to other processes.

45. Contextual Equivalences Much the same as for CCS: Barbs and contexts are easily adapted: We obtain the same hierarchy of equivalences We have the same equations for CCS processes seen as Pi processes. We can now relate more interesting processes.

46. Labelled Semantics How to get rid of structural equivalence ? Labelled bisimilarity = barbed congruence ? Output labels can now carry along “extruded names”:

47. A Labelled Semantics

48. Labelled Bisimilarity Labelled (weak) simulation property: A relation R is a labelled bisimulation when R and R -1 meet (S) and (S  ). Labelled bisimilarity is the largest labelled bisimulation Congruence for evaluation contexts Finer than barbed congruence With convenient proof techniques

49. 01/05/2015 Agay Spring School, March'02 Encodings

50. Example: Sending Tuples We can encode richer forms of communication using communication protocols on private channels. We could also exchange messages in both directions We need a private channel c for each tuple; otherwise, parallel communications may get mixed.

51. Example: Sending Tuples (2) Correctness? The first communication step in the translation corresponds to the source communication step Further steps are local and deterministic: No full abstraction (for barbed congruence): the context can block some communications

52. Example: Data Milner’s Booleans: Integers are similarly encoded Two continuations, for zero and for succ. Are these good encodings? Operational correspondence No full abstraction: the context can observe too much (cf games semantics) we need restrictions (e.g. types) to fix this problem.

53. Process Mobility Do we need higher-order mobility? Technically tricky: Scoping rules get complicated (sharing, substitutions) Labelled transitions become too precise Blue Calculus [Boudol], …

54. Encoding Process Mobility (1) Instead of passing a process, we pass a fresh name representing that process. Is it a good encoding ?

55. Encoding Process Mobility (2) Operational correspondence:

56. Encoding Process Mobility (3) Operational correspondence Full abstraction (for barbed congruence) at least for processes that use higher-order internally. Informally, this encoding is not local: passing a pointer to a process instead of passing a copy of the process.

57. Encoding Functions How to encode the lambda calculus in Pi ? 1. Choose an evaluation strategy 2. Perform a CPS transform 3. Encode abstractions using higher-order processes. Much like simpler datatypes: We easily obtain operational correspondence We don’t have full abstraction (at least without types) because the context can detect function calls.

58. 01/05/2015 Agay Spring School, March'02 Variations on Name Mobility

59. Which communication model? In CCS, In Pi: channel-based handshakes. There are many interesting restrictions and alternatives: Internal Mobility: Pi-I [Boreale & Sangiorgi]: One can communicate only new names: Input and output are symmetric again! We still “essentially” have the pi calculus Fusions [Victor] Names are globally “fused” when passed as parameters

60. Asynchrony Asynchronous Pi Calculus [Boudol, Honda & Tokoro] When sending a message, there is no direct mechanism to detect that the message has been received. Asynchronous laws (insensitive to buffering). Contexts have less discriminative power. There are (global) encodings As a core programming language, much easier to implement! Asynchrony, equators, and this kind of stuff ?? Important to understand that name mobility (as reflected in the labelled semantics) is just an encoding trick, not something that can necessarily be tracked step by step.

61. Locality Even in the asynchronous Pi, communication occurs “in the ether”. This is sometimes too abstract. How to rule out any hidden dynamic synchronization? The Join Calculus [Fournet & Gonthier] When fresh names are introduced, a series of inputs for those names are statically defined, once for all. One can only send on a received channel. A-Pi [Merro & Sangiorgi] Name mobility applies only to the “output” capability

62. Types Using types for names and processes, one can enforce various communication disciplines. Consistent arities for communication Polarity (input/output), Linearity Communication patterns: processes as types Behavioural properties: deadlock freedom Typed equivalence The observer must be a well-typed context This is often necessary to get full-abstraction Typed translations, for instance from lambda calculi to the pi calculus [Honda et al.] Types for security

63. Programming Languages Facile, CML: programming with CCS channels higher-order communication in message contents. Occam (CSP) PICT (’95): an asynchronous Pi calculus as a core language for concurrent programming. JCL, JoCaml : the join calculus as a core language for distributed/mobile programming. Klaim, and coordination languages a tuple space = a large channel Databases and workflow languages

64. Conclusions Mobile names naturally represent dynamic capabilities, such as communication capabilities. Mobility for fresh names is very expressive. Dynamic configuration Local encodings Higher-order mobility can (sometimes) be reduced to channel mobility. Names don’t have to be channels names! Cookies, Tokens, UIDs Dynamic memory: “new” creates a fresh memory location Security: cryptographic keys