Rpc (async_rpc_kernel.Async_rpc

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 Rpc.t, a 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.

The 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 Implementation.ts.

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

A 'connection_state Implementation.t is something that knows how to respond to one query, given a 'connection_state. That is, you can create a 'connection_state Implementation.t by providing a function which takes a query *and* a 'connection_state and provides a response.

module Implementations : sig ... end

A 'connection_state Implementations.t is something that knows how to respond to many different queries. It is conceptually a package of 'connection_state Implementation.ts.

module Transport = Transport

module Connection : Connection_intf.S

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.