TcpSocketOperationalSemantics-0.3.0-draft.md

Operational semantics of WASI TCP sockets

WASI TCP sockets must behave as-if they are implemented using the state machine described in this document.

States

Note: These refer to the states of the TCP socket, not the TCP connection

In pseudo code:

interface tcp {
    variant state {
        unbound,
        bound,
        listening(accept-stream),
        connecting(connect-future),
        connected,
        closed(option<error-code>),
    }
}

Transitions

The following diagram describes the exhaustive set of all possible state transitions:

stateDiagram-v2
    state "unbound" as Unbound
    state "bound" as Bound
    state "connecting" as Connecting
    state "connected" as Connected
    state "listening" as Listening
    state "closed" as Closed


    [*] --> Unbound: create-tcp-socket() -> ok
    Unbound --> Bound: bind() -> ok
    Unbound --> Connecting: connect()

    Connecting --> Connected: «task resolves successfully»
    Connecting --> Closed: «task resolves with error»

    Connected --> Closed: «connection terminated»

    Bound --> Connecting: connect()
    Bound --> Listening: listen() -> ok
    Unbound --> Listening: listen() -> ok

Loading

• Transitions annotated with -> ok only apply when the method returns successfully.
• Calling a method from the wrong state returns error(invalid-state) and does not affect the state of the socket.
• This diagram only includes the methods that impact the socket's state. For an overview of all methods and their required states, see tcp.wit
• Client sockets returned by listen() are immediately in the connected state.
• A socket resource can be dropped in any state.