This documents the protocol used to communicate between the client and server of Ensync. This is mainly useful if you want to write some other server backend.
MUST, MAY, and so forth follow the usual meaning.
No underlying transport protocol is specified, though it must inherently be an ordered byte stream. No encryption or authentication is included, as this is is left to the underlying transport. Similarly, there are no defined keep-alives or timeouts here.
The server and the client send streams of fourleaf values conforming to the
Response and Request enums defined in rpc.rs, respectively.
Depending on the type, each client frame may require the server to send one or
more response frames. The server MUST NOT send unsolicited frames, except as
enabled by specific requests and that it MAY send an unsolicited FatalError
response immediately before terminating communication to indicate a fatal
error, since FatalError is an acceptable response for whatever frame the
client may later send.
The client MAY continue sending frames even when the most recent frame is still
pending a response from the server. The server MUST send responses in the same
order as their corresponding requests. The server MAY process requests in a
different order than they are received, except that requests involving a single
transaction may not be reordered with each other, and requests which read items
MUST NOT be ordered before a Commit which was received first if this would
produce an observable difference.
Each request type (other than ClientInfo) corresponds to exactly one method
in the Storage trait; the exact semantics are documented there.