Create a mux handle in Mode and register mini-protocols.

Mux handle which allows to control the multiplexer, e.g.

• run: run the multiplexer
• runMiniProtocol: start a mini-protocol (eagerly or lazily)
• stop: stop the multiplexer, causing run to return.

Statically configured multiplexer mode.

A static description of a mini-protocol.

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

run 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

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

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 Error` 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 run. In this case the protocol thread will not actually start until run is called, irrespective of the StartOnDemandOrEagerly value.

Strategy how to start a mini-protocol.

Channel using ByteString.

A channel which can send and receive values.

It is more general than what `network-mux` requires, see ByteChannel instead. However this is useful for testing purposes when one is either using mux or connecting two ends directly.

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

• socketAsBearer
• pipeAsBearer

• Test.Mux.queuesAsBearer

Get information about all statically registered mini-protocols.

Await until mux stopped.

Enumeration of error conditions.

Enumeration of Mux events that can be traced.

Type used for tracing mux events.