Plasma GitLab Archive
Projects Blog Knowledge

Previous  Up  Next

Module Rpc_client


module Rpc_client: sig .. end
RPC clients

This module implements an RPC client, i.e. provides means to connect to an RPC service and call remote procedures. In general, this module works in an asynchronous way and is implemented event-driven. All events are handled by an event queue of type Unixqueue.t that must already exist and to which this module adds its own event handlers and event resources. This means that this module can co-exist with other services and share the same event queue with them.

You can push several procedure calls on the event queue at once. The queue serves then as a pipeline; the calls are sent to the server as long as the server accepts new calls. Replies are received in any order, and the return values of the remote procedures are delivered using a callback function.

You can set timeouts and force automatic retransmission if you want this; these features are enabled by default if the underlying transport mechanism is UDP. Timeouts and other exceptions are delivered to the callback functions, too.

The whole mechanism is designed to allow maximum parallelism without needing to use the multi-threading features of O'Caml. Especially, the following parallelisms can be done:

  • Call several procedures of the same server in parallel. Note that this does not necessarily mean that the procedures are run in parallel since the server is free to decide whether to work in a synchronous or asynchronous way.
  • Call several procedures of different servers in parallel. To do so, simply add several RPC clients to the same event queue.
  • Call a procedure and do something completely different in the background; this works well as long as the other task can be programmed using file descriptor events, too.
However, there are still some restrictions concerning asynchronous calls. Some of them will be removed in the future, but others are difficult to tackle:
  • Authentication methods requiring RPC calls or other network services are performed in an synchronous way, too.
  • Name service lookups are synchronous, too.

exception Message_lost
got EOF when some pending procedure calls were not replied or even sent
exception Message_timeout
After all retransmissions, there was still no reply
exception Response_dropped
Drop reason: The response exceeded the configured maximum message size
exception Communication_error of exn
an I/O error happened
exception Client_is_down
The RPC call cannot be performed because the client has been shut down in the meantime. You can get this exception if you begin a new call, but the connection is closed now.
exception Keep_call
This exception can be raised by the callback function that is invoked when the server response arrives. It causes that the RPC call record is kept in the housekeeping structure of the client. If the server sends another response, the callback function will be invoked again. I.e. one call can be replied several times (server-driven batching).
exception Unbound_exception of exn
This exception can be raised by the callback function that is invoked when the server response arrives. It simply causes that the inner exception bypasses the exception handler, and falls through to the caller of Unixqueue.run. This is useful to jump out of the running RPC routines.
type t
The type of RPC clients

type connector =
| Inet of (string * int) (*Hostname or IP address, port*)
| Internet of (Unix.inet_addr * int) (*The address plus port*)
| Unix of string (*Path to unix dom sock. Not supported on Win32.*)
| W32_pipe of string (*Path to named pipe (only Win32)*)
| Descriptor of Unix.file_descr (*Pass an already open socket descriptor. The descriptor will not be closed when the client is done! On Win32, the proxy descriptors as returned by Netsys_win32.pipe_descr are also accepted.*)
| Dynamic_descriptor of (unit -> Unix.file_descr) (*The function is called to get the socket descriptor. Unlike Descriptor, the descriptor will be closed when the client is done (unless it is a proxy descriptor)*)
| Portmapped of string (*The portmapper on this host is queried to get address information*) 
val shutdown_connector : t ->
       Rpc_transport.rpc_multiplex_controller -> (unit -> unit) -> unit
The default implementation to shut down the connector. Actions are triggered that will take the connector down at some time in the future. At this time, the callback function is invoked.

For Descriptor connector the socket is shut down but not closed. For the other connector types the socket is also closed. Win32 named pipes are shut down.

class type socket_config = object .. end
Configuration for `Socket (see below). 
val default_socket_config : socket_config
Default configuration with non_blocking_connect = true
class default_socket_config : socket_config
Default configuration as class 
val blocking_socket_config : socket_config
Configuration with non_blocking_connect = false
class blocking_socket_config : socket_config
blocking connect configuration as class 
type mode2 = [ `Multiplexer_endpoint of Rpc_transport.rpc_multiplex_controller
       | `Socket of Rpc.protocol * connector * socket_config
       | `Socket_endpoint of Rpc.protocol * Unix.file_descr ]
Determines the type of the client for create2:

  • `Socket_endpoint(proto,fd): Socket fd is a connected socket descriptor used for communication. proto determines the encapsulation; should be Tcp for stream sockets and Udp for datagram sockets. The descriptor will be closed when the client terminates.
  • `Multiplexer_endpoint m: m is an RPC multiplex controller.
  • `Socket(proto, conn, config): Creates and connect a client socket according to conn. proto determines the encapsulation; should be Tcp for stream sockets and Udp for datagram sockets. config specifies configuration details.

val create2 : ?program_number:Rtypes.uint4 ->
       ?version_number:Rtypes.uint4 ->
       ?initial_xid:int ->
       ?shutdown:(t ->
                  Rpc_transport.rpc_multiplex_controller -> (unit -> unit) -> unit) ->
       mode2 -> Rpc_program.t -> Unixqueue.event_system -> t
New style clients: Opens a connection to the server specified by mode2. The server is assumed to implement an RPC program as specified by the Rpc_program.t argument. (You can override the program and version numbers stored in this argument by the optional parameters program_number and version_number. If you need to call several programs/versions with the same client, use unbound_create instead.)

All communication to the server is handled using the given queue Unixqueue.event_system. There is a limit of 2GB per message or Sys.max_string_length, whatever is lower.

If the protocol (passed along with mode2) is Tcp, the communication will be handled stream-oriented. In this case, no timeout is detected and no retransmissions are done.

If the protocol is Udp, a datagram-oriented communication style is used. This works only for Internet UDP sockets because these are bidirectional (Unix domain sockets are unidirectional and do not work). For Udp, there is a timeout of 15 seconds and a maximum of 3 retransmissions (i.e. a total of 4 transmission trials). For connected UDP sockets there is a limit of 64K per message (max. size of an Internet packet). For unconnected UDP sockets there is a limit of 16K per message due to restrictions in the OCaml runtime.


program_number : Overrides the program number in Rpc_program.t
version_number : Overrides the version number in Rpc_program.t
initial_xid : The initial value for the session identifier.
shutdown : This function is called when the client is shut down to close the client socket. By default, shutdown_connector is called.
val unbound_create : ?initial_xid:int ->
       ?shutdown:(t ->
                  Rpc_transport.rpc_multiplex_controller -> (unit -> unit) -> unit) ->
       mode2 -> Unixqueue.event_system -> t
Creates an unbound client. This is like create2, but the client is not restricted to a particular RPC program.

One can convert an unbound client into a bound client by calling bind, see below. It is possible to bind several times, so several programs can be called with the same client (provided the server is also capable of dealing with several programs).

This function does not support Portmapped connectors.

val bind : t -> Rpc_program.t -> unit
Binds this program additionally
val use : t -> Rpc_program.t -> unit
If there are no bound programs, this is a no-op. Otherwise it is checked whether the passed program is bound. If not, an exception is raised.

Programs are compared by comparing Rpc_program.id. The program must be the same value, but it is also allowed to Rpc_program.update it in the meantime, i.e. to change program and version numbers.

val configure : t -> int -> float -> unit
configure client retransmissions timeout: sets the number of retransmissions and the timeout for the next calls. (These values are defaults; the actual values are stored with each call.)

Values of retransmissions > 0 are semantically only valid if the called procedures are idempotent, i.e. invoking them several times with the same values has the same effect as only one invocation. Positive values for retransmissions should only be used for Udp-style communication.

The timeout value determines how long the client waits until the next retransmission is done, or, if no more retransmissions are permitted, a Message_timeout exception is delivered to the receiving callback function. A timeout value of 0.0 means immediate timeout (see next paragraph). A negative timeout value means 'no timeout'. Positive timeout values are possible for both Udp and Tcp connections. Timeout values are measured in seconds.

There is a special application for the timeout value 0.0: If you don't expect an answer from the server at all ("batch mode"), this timeout value will cause that the message handler will get a Message_timeout exception immediately. You should ignore this exception for batch mode. The positive effect from the timeout is that the internal management routines will remove the remote call from the list of pending calls such that this list will not become too long. (You can get a similar effect by calling set_batch_call, however.)

Note that the meaning of timeouts for TCP connections is unclear. The TCP stream may be in an undefined state. Because of this, the client does not make any attempt to clean the state up for TCP. The user is advised to shut down the client, and reconnect.

There is another subtle difference between UDP and TCP. For UDP, the timer is started when the packet is sent. For TCP, however, the timer is already started when the RPC call is added to the queue, i.e. much earlier. This means that the time for connecting to the remote service is also bound by the timeout. The rationale is that TCP timeouts are usually set to catch total service failures rather than packet losses, and this behaviour is best for this purpose.

val configure_next_call : t -> int -> float -> unit
Same as configure, but it only affects the next call
val set_dgram_destination : t -> Unix.sockaddr option -> unit
set_dgram_destination client addr_opt: This function is required for using the client in conjunction with unconnected UDP sockets. For connected sockets, the destination of datagrams is implicitly given. For unconnected sockets, one has to set the destination explicitly. Do so by calling set_dgram_destination with Some addr as addr_opt argument before calling. Passing None as addr_opt removes the explicit destination again. Note that unconnected sockets differ from connected sockets also in the relaxation that they can receive messages from any IP address, and not only the one they are connected to.

The current destination is used for all following calls. It is not automatically reset to None after the next call.

val set_batch_call : t -> unit
The next call will be a batch call. The client does not wait for the response of a batch call. Instead, the client immediately fakes the response of a "void" return value.

It is required that the batch call has a "void" return type. Otherwise, the client raises an exception, and ignores the call.

This setting only affects the next call.

val set_max_response_length : t -> int -> unit
Sets the maximum length of responses. By default, there is only the implicit maximum of Sys.max_string_length.

If the maximum is exceeded, the exception Response_dropped is raised.

val set_exception_handler : t -> (exn -> unit) -> unit
sets an exception handler (the default prints the exception with `Crit level to the logger set in Netlog). Only exceptions resulting from invocations of a callback function are forwarded to this handler (unless wrapped by Unbound_exception).

Exceptions occuring in the handler itself are not caught, and will fall through.

val event_system : t -> Unixqueue.event_system
Returns the unixqueue to which the client is attached
val programs : t -> Rpc_program.t list
Returns the list of all bound programs
val get_socket_name : t -> Unix.sockaddr
val get_peer_name : t -> Unix.sockaddr
Return the addresses of the client socket and the server socket, resp. Note that these are only available when the client is already connected. The function calls fail otherwise. It is also possible that the underlying transport mechanism does not know these data.
val get_sender_of_last_response : t -> Unix.sockaddr
Return the address of the sender of the last received response.
val get_protocol : t -> Rpc.protocol
Get the protocol flavour
val is_up : t -> bool
Return whether the client is up
val unbound_sync_call : t -> Rpc_program.t -> string -> Xdr.xdr_value -> Xdr.xdr_value
unbound_sync_call client pgm proc arg: Invoke the remote procedure proc of the program pgm via client. The input arguments are arg. The result arguments are returned (or an error is raised)
val unbound_async_call : t ->
       Rpc_program.t ->
       string -> Xdr.xdr_value -> ((unit -> Xdr.xdr_value) -> unit) -> unit
unbound_ssync_call client pgm proc arg emit: Invoke the remote procedure proc of the program pgm via client. The input arguments are arg. When the result r is available, the client will call emit (fun () -> r) back. When an exception e is available, the client will call emit (fun () -> raise e) back.
class unbound_async_call : t -> Rpc_program.t -> string -> Xdr.xdr_value -> [Xdr.xdr_value] Uq_engines.engine
Same as unbound_async_call, but with an engine API. 
val synchronize : Unixqueue.event_system -> ('a -> ((unit -> 'b) -> unit) -> unit) -> 'a -> 'b
Turns an async call into a synchronous call
val shut_down : t -> unit
Shuts down the connection. Any unprocessed calls get the exception Message_lost. It is no error to shut down a client that is already down - nothing happens in this case.

Shutdowns can be complex operations. For this reason, this function implements some magic that is usually the right thing, but may also be wrong:

  • If called outside the event loop, it is assumed that a synchronous shutdown is desired, and the event loop is started to complete the shutdown immediately. This is right when the only task connected with the event loop is the shutdown, which is then done, and this function returns finally to the caller. If there are other tasks on the event loop, these tasks are also run, however, which may lead to side effects and infinite delay. This can be wrong.
  • If called from within the event loop, the shutdown is only triggered but not immediately done. When the caller returns to the event loop the shutdown will be performed. This case is problematic when you pass the file descriptor explicitly with Descriptor to the client. You don't know when the client is finally down, and the descriptor can be closed.
The following functions allow more fine grained control of the shutdown.
val sync_shutdown : t -> unit
Enforces a synchronous shutdown of the connection. This is only possible if called from outside the event loop. This function fails if called from within the event loop.

You can be sure that the shutdown is completely done when this function returns normally.

val trigger_shutdown : t -> (unit -> unit) -> unit
Triggers the shutdown, and calls the passed function back when it is done.

The function is not only called when the client has to be taken down, but also if the client is already down.

class type auth_session = object .. end
An auth_session object is normally created for every client instance. 
class type auth_method = object .. end
An auth_method object represents a method of authentication. 
val auth_none : auth_method
The authentication method that does not perform authentication.
val set_auth_methods : t -> auth_method list -> unit
Set the authentication methods for this client. The passed methods are tried in turn until a method is accepted by the server. The default is auth_none 
module type USE_CLIENT = sig .. end
This module type is what the generated "clnt" module assumes about the client interface

Deprecated Interfaces


val create : ?program_number:Rtypes.uint4 ->
       ?version_number:Rtypes.uint4 ->
       ?initial_xid:int ->
       ?shutdown:(t ->
                  Rpc_transport.rpc_multiplex_controller -> (unit -> unit) -> unit) ->
       Unixqueue.event_system ->
       connector -> Rpc.protocol -> Rpc_program.t -> t
Deprecated.This function should not be used any more in new programs. Use create2 or unbound_create.
Opens a connection to the server specified by the connector. The server is assumed to implement an RPC program as specified by the Rpc_program.t argument. (You can override the program and version numbers stored in this argument by the optional parameters program_number and version_number.)

All communication to the server is handled using the given queue Unixqueue.event_system.

If the protocol is Tcp, the communication will be handled stream- oriented. In this case, no timeout is detected and no retransmissions are done.

If the protocol is Udp, a datagram-oriented communication style is used. This works only for Internet UDP sockets because these are bidirectional (Unix domain sockets are unidirectional and do not work). For Udp, there is a timeout of 15 seconds and a maximum of 3 retransmissions (i.e. a total of 4 transmission trials).

Unlike create2, servers made with create always use blocking connect for backwards compatibility.


program_number : Overrides the program number in Rpc_program.t
version_number : Overrides the version number in Rpc_program.t
initial_xid : The initial value for the session identifier.
shutdown : This function is called when the client is shut down to close the client socket. By default, shutdown_connector is called.
val program : t -> Rpc_program.t
Deprecated.This is the same as List.hd (Rpc_client.programs client)
Returns the program the client represents.
val add_call : t ->
       string -> Xdr.xdr_value -> ((unit -> Xdr.xdr_value) -> unit) -> unit
Deprecated.add_call is restricted to the case that there is only one bound program. It will fail in other cases. Use unbound_async_call instead. Note also that there is no longer the optional when_sent argument. Use set_batch_call instead
add_call client proc_name arg f: add the call to the procedure name with argument arg to the queue of unprocessed calls.

When the reply has arrived or an error situation is detected, the function f is called back. The argument of f is another function that will return the result or raise an exception: 

 let my_f get_result =
      try
        let result = get_result() in
        ...
      with
         exn -> ...
    in
    add_call client name arg my_f

If f does not catch the exception, the pluggable exception handler of the client is called (see set_exception_handler). Exceptions are either Message_lost, Message_timeout, or Communication_error.

The function f can raise the exception Keep_call to indicate the special handling that a further reply of the call is expected (batching). 


val sync_call : t -> string -> Xdr.xdr_value -> Xdr.xdr_value

Calls the procedure synchronously. Note that this implies that the underlying unixqueue is started and that all events are processed regardless of whether they have something to do with this call or not. 


val verbose : bool -> unit
set whether you want debug messages or not (same as setting Rpc_client.Debug.enable)

Debugging


module Debug: sig .. end
This web site is published by Informatikbüro Gerd Stolpmann
Powered by Caml