PingPong
This example implements interaction between two parties, Alice and Bob, in which
- Alice sends "ping" to Bob,
- Bob sends "pong" back to Alice,
- Alice sends Done to Bob,
in this order, after which no more interaction between the two takes place.
This example demonstrates:
- A simple protocol between two parties.
- Linearity: obligation to consume every input exactly once and fulfill every demand exactly once. Linearity is key to ensuring adherence to a protocol.
- Inverting the flow of values from left-to-right to right-to-left and vice versa.
Type members
Types
The protocol expresses that:
┃
┞───────────┐
┄┄→╎Val["ping"]│┄┄→
┟───────────┘
┃
┞───────────┐
←┄┄╎Neg["pong"]│←┄┄
┟───────────┘
┃
┞───────────┐
┄┄→╎ Done │┄┄→
┟───────────┘
┃
Val[A]
is a value of typeA
traveling left-to-right (the positive direction).Neg[A]
is a value of typeA
traveling right-to-left (the negative direction). It can be thought of as a demand forA
, analogous toPromise[A]
from the Scala library.Done
is a signal traveling left-to-right. It carries no additional information (it is likeVal[Unit]
).
The protocol expresses that:
- The party to the left has to send
"ping"
, receive"pong"
and send a Done signal. - Dually, the party to the right has to receive
"ping"
, send"pong"
and receive a Done signal.
Note: The protocol does not dictate any order in which data flows through the three ports—it may all happen concurently. However, the two interacting parties below are defined in so that the interaction proceeds sequentially top-to-bottom (wrt. the above depiction).
Inherited types
- Inherited from
- StarterAppBase
- Inherited from
- StarterAppBase
- Inherited from
- StarterAppBase
- Inherited from
- StarterAppBase
- Inherited from
- StarterAppBase
- Inherited from
- StarterAppBase
- Inherited from
- StarterAppBase
- Inherited from
- StarterAppBase
- Inherited from
- StarterAppBase
- Inherited from
- StarterAppBase
- Inherited from
- StarterAppBase
- Inherited from
- StarterAppBase
- Inherited from
- StarterAppBase
Value members
Concrete methods
Alice is on the left side of Protocol.
Alice is on the left side of Protocol.
┏━━━━━━━━━━━━━━━━━┓
┞──────┐ ┞───────────┐
╎ Done │┄┄┄┄┄┄┄┄┄→╎Val["ping"]│┄┄→
┟──────┘ ┟───────────┘
┃ ┃
┃ ┞───────────┐
┃ alice ┌┄←┄╎Neg["pong"]│←┄┄
┃ ┆ ┟───────────┘
┃ ┆ ┃
┃ ┆ ┞───────────┐
┃ └┄→┄╎ Done │┄┄→
┃ ┟───────────┘
┗━━━━━━━━━━━━━━━━━┛
Receives a Done signal from the left, in response to which it sends a "ping"
to the right.
Concurrently, it receives a "pong"
from the right, in response to which it sends a Done signal to the right.
Connects alice and bob, resulting in
┏━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━┓
┞──────┐ ┞───────────┐ ┃
╎ Done │┄┄┄┄┄┄┄┄┄→╎Val["ping"]│┄→┄┐ ┃
┟──────┘ ┟───────────┘ ┆ ┃
┃ ┃ ┆ ┃
┃ ┞───────────┐ ┆ ┃
┃ alice ┌┄←┄╎Neg["pong"]│┄←┄┘ ┃
┃ ┆ ┟───────────┘ ┃
┃ ┆ ┃ bob ┃
┃ ┆ ┞───────────┐ ┞──────┐
┃ └┄→┄╎ Done │┄┄┄┄┄┄┄┄→╎ Done │
┃ ┟───────────┘ ┟──────┘
┗━━━━━━━━━━━━━━━━━┻━━━━━━━━━━━━━━━━━━━━━┛
This effectively sequences the whole interaction.
The resulting shape is Done -⚬ Done
. Thanks to linearity, the whole diagram is well-wired.
It is impossible to construct a component that has unconnected or multiply-connected ports inside.
All unconnected ports are on the outside, part of the component's interface.
- Definition Classes
- StarterApp
Bob is on the right side of Protocol.
Bob is on the right side of Protocol.
┏━━━━━━━━━━━━━━━━━━━━━┓
┞───────────┐ ┃
┄┄→╎Val["ping"]│┄→┄┐ ┃
┟───────────┘ ┆ ┃
┃ ┆ ┃
┞───────────┐ ┆ ┃
←┄┄╎Neg["pong"]│┄←┄┘ ┃
┟───────────┘ ┃
┃ bob ┃
┞───────────┐ ┞──────┐
┄┄→╎ Done │┄┄┄┄┄┄┄┄→╎ Done │
┟───────────┘ ┟──────┘
┗━━━━━━━━━━━━━━━━━━━━━┛
Receives a "ping"
from the left, in response to which it sends a "pong"
to the left.
Concurrently, it receives a Done signal from the left and forwards it to the right.
Inherited methods
Extensions
Implicits
Inherited implicits
Exports
Inherited defined exports
- Inherited from
- StarterAppBase
- Inherited from
- StarterAppBase