Module frame

Frame data types for describing the wire format abstractly.

In this context, we use “client” to refer to the initiator that makes an outgoing connection and “server” to refer to the responder that receives an incoming connection. This doesn’t have to map onto high-level protocol concepts in the consumer, naturally.

Structs

ChallengeData

Challenge data used when identifying self. This includes a nonce that we’ll use with another nonce for the challenge.

ClientFinishData

Finishes the client’s side of the handshake if we’re identifying ourselves. This is omitted if we’re not doing the full self-identification handshake.

ClientHelloData

Initial message client sends to server to begin identifying itself and pick the protocol.

ClientQueryData

Query for the protocols the server supports.

CloseData

Frame

FrameHeader

GoodbyeData

Sent before closing a connection.

MsgFlags

Flags sent along with a message payload to signal various conditions.

NotificationData

OpenData

Data passed when opening a new channel. Channel ID is implicit.

PushData

Data passed when pushing data on a channel.

ResponseData

Protocol-specific response message, which we expect to be a signature and maybe the also the pubkey we’re identifying ourselves as.

ServerDumpData

Response to the query of the protocols the server supports.

ServerHelloData

Acknowledgement of the ClientHello and the choice of protocol. Includes challenges and responses as necessary.

Enums

AuthIntent

Describes what auth relationship we want to set up with the server. This ignores any authentication that may be provided by the underlying transport.

FrameBody

Roughly parsed frame body.

FrameType

Side

Viewpoint-agnostic side of a channel, where client is generically the initator and server is generically the acceptor.