pub struct MultiMessage<P, R> {
pub protocol_id: P,
pub payload: R,
}Expand description
A multiplexed message, consisting of the ID of the protocol and dynamic content that only the corresponding session will know how to handle, and check if it is indeed the next expected message.
A message like this is coming from or going to a specific network connection. It is assumed that there is no need to identify the remote party, since the protocol would only be talking to one party at a time that already got determined at connection time.
We can probably assume that there will be only one instance
of each protocol per remote party, so P will be a simple
static identifier for the protocol. If that’s not the case,
it could be more complex, like a unique session ID.
It is up to some higher level component to handle the wire
format of the message, including turning the payload and
the protocol ID into binary or JSON for example. This is
what the Repr allows us to do, e.g. to have each message
implement serde, wrap then in an enum, that gets serialised
at the edge of the system to/from JSON.
A network connection will be either incoming or outgoing, i.e. for Alice to follow Bob and for Bob to follow Alice they will need 2 TCP connections, one from Alice to Bob and another from Bob to Alice. If it wasn’t so we would need a way to differentiate between two instances of the same protocol, a unique session ID for each message.
Another way of doing it would be to add two flags to the message:
- indicate the direction of the connection, incoming or outgoing
- indicate whether the protocol was initiated by the source or the target of the connection.
This would facilitate all communication over a single TCP connection, however we would need to start with protocol negotiation to find out if the other side even supports serving certain protocols. It would also make it more difficult to tell if a connection can be closed, because we wouldn’t know if the other side has interest in keeping it open even if currently there are no sessions.
Fields§
§protocol_id: PThe protocol ID features explicitly in the message, rather than
as a type class, because for example with DynMessage we don’t
have a unique mapping between a message type and its protocol.
For example multiple protocols can expect a String.
payload: RThe payload is the Repr representation of the message,
to be (un)wrapped by the session.