Module ecksport_core::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.