Application run by mux layer.

• enumeration of client application, e.g. a wallet application communicating with a node using ChainSync and TxSubmission protocols; this only requires to run client side of each protocol.
• enumeration of server applications: this application type is mostly useful tests.
• enumeration of both client and server applications, e.g. a full node serving downstream peers using server side of each protocol and getting updates from upstream peers using client side of each of the protocols.

The wire format includes the protocol numbers, and it's vital that these are stable. They are not necessarily dense however, as new ones are added and some old ones retired. So we use a dedicated class for this rather than reusing Enum. This also covers unrecognised protocol numbers on the decoding side.

Per Miniprotocol limits

runMux starts a mux bearer for the specified protocols corresponding to one of the provided Versions.

Isometric flow control: analysis of head-of-line blocking of the ingress side of the multiplexer

For each mini-protocol (enumerated by ptcl), mux will create two channels. One for initiator and one for the responder. Each channel will use a single Wanton. When it is filled, it is put in a common queue tsrQueue. This means that the queue is bound by 2 * |ptcl|. Every side of a mini-protocol is served by a single Wanton: when an application sends data, the channel will try to put it into the Wanton (which might block). Wantons are taken from the tsrQueue queue by one of mux threads. This eliminates head of line blocking: each mini-protocol thread can block on putting more bytes into its Wanton, but it cannot block the other mini-protocols or the thread that is reading the tsrQueue queue. This is ensured since the muxChannel will put only a non-empty Wanton to the tsrQueue queue, and on such wantons the queue is never blocked. This means that the only way the queue can block is when its empty, which means that none of the mini-protocols wanted to send. The egress part will read a Wanton, take a fixed amount of bytes encode them in as an MuxSDU; if there are leftovers it will put them back in the Wanton and place it at the end of the queue (reading and writing to it will happen in a single STM transaction which assures that the order of requests from a mini-protocol is preserved.

Properties:

• at any given time the tsrQueue contains at most one TranslocationServiceRequest from a given mini-protocol of the given MiniProtocolDir, thus the queue contains at most 2 * |ptcl| translocation requests.
• at any given time each TranslocationServiceRequest contains a non-empty Wanton

Arrange to run a protocol thread (for a particular MiniProtocolNum and MiniProtocolDirection) to interact on this protocol's Channel.

The protocol thread can either be started eagerly or on-demand:

• With StartEagerly, the thread is started promptly. This is appropriate for mini-protocols where the opening message may be sent by this thread.
• With StartOnDemand, the thread is not started until the first data is received for this mini-protocol. This is appropriate for mini-protocols where the opening message is sent by the remote peer.

The result is a STM action to block and wait on the protocol completion. It is safe to call this completion action multiple times: it will always return the same result once the protocol thread completes. In case the Mux has stopped, either due to an exception or because of a call to muxStop a `Left MuxError` will be returned from the STM action.

It is an error to start a new protocol thread while one is still running, for the same MiniProtocolNum and MiniProtocolDirection. This can easily be avoided by using the STM completion action to wait for the previous one to finish.

It is safe to ask to start a protocol thread before runMux. In this case the protocol thread will not actually start until runMux is called, irrespective of the StartOnDemandOrEagerly value.

Shut down the mux. This will cause runMux to return. It does not wait for any protocol threads to finish, so you should do that first if necessary.

Low level access to underlying socket or pipe. There are three smart constructors:

• socketAsMuxBearer
• pipeAsMuxBearer

• Test.Mux.queuesAsMuxBearer

Await until mux stopped.

Error type used in across the mux layer.

Enumeration of error conditions.

Enumeration of Mux events that can be traced.

Type used for tracing mux events.