A library for building asynchronous RPC-style protocols.
The approach here is to have a separate representation of the server-side implementation of an RPC (An
Implementation.t) and the interface that it exports (either an
State_rpc.t or a
Pipe_rpc.t, but we'll refer to them generically as RPC interfaces). A server builds the
Implementation.t out of an RPC interface and a function for implementing the RPC, while the client dispatches a request using the same RPC interface.
Implementation.t hides the type of the query and the response, whereas the
Rpc.t is polymorphic in the query and response type. This allows you to build a
Implementations.t out of a list of
Each RPC also comes with a version number. This is meant to allow support of multiple different versions of what is essentially the same RPC. You can think of it as an extension to the name of the RPC, and in fact, each RPC is uniquely identified by its (name, version) pair. RPCs with the same name but different versions should implement similar functionality.
module Description : sig ... end
module Implementation : sig ... end
'connection_state Implementation.t is something that knows how to respond to one query, given a
'connection_state. That is, you can create a
Implementation.t by providing a function which takes a query *and* a
'connection_state and provides a response.
module Implementations : sig ... end
'connection_state Implementations.t is something that knows how to respond to many different queries. It is conceptually a package of
module Transport : sig ... end
RPC transport layer
module Connection : sig ... end
module Rpc : sig ... end
module Pipe_close_reason : sig ... end
module Pipe_rpc : sig ... end
module State_rpc : sig ... end
A state rpc is an easy way for two processes to synchronize a data structure by sending updates over the wire. It's basically a pipe rpc that sends/receives an initial state of the data structure, and then updates, and applies the updates under the covers.
module One_way : sig ... end
An RPC that has no response. Error handling is trickier here than it is for RPCs with responses, as there is no reasonable place to put an error if something goes wrong. Because of this, in the event of an error such as dispatching to an unimplemented RPC, the connection will be shut down. Similarly, if the implementation raises an exception, the connection will be shut down.
module Any : sig ... end