Introduction
The issue is how to invoke a method which is located in a different process or even different machine on the network? This question causes a lot of solutions to appear such as DCOM (Distributed Component Object Model) by Microsoft, CORBA (Common Object Request Broker Architecture) which is cross platform independent, Java RMI (Remote Method Invocation)… These are generally called RPC (Remote Procedure Call).
OpenClovis defined and implemented their own RPC called RMD (Remote Method Dispatch)
Overview
In a system with a single address space, function calls made are local to the address space. However, in a distributed system, the services sought by a caller may not always be available locally, but at some remote node. Remote Method Dispatch or RMD facilitates calls to the remote callee and returns the results to the caller. From the point of view of the caller, and RMD call looks exactly like a local function call. However, the function is actually executed on another node. Details like what node provides the service, how to communicate with this node, and platform specifics like endianess is hidden from the caller.
Features
- A technology to implement RPC
- Enables you to make a function call in another process, irrespective of the location of the process
- Communication takes place over low latency IOC/TIPC layer
- Reliable communication (“at most once” semantics)
- Support both synchronous and asynchronous flavors
- IDL can be used to generate client/server stubs for user components (and is of course used internally for SAFplus Platform components)
- Platform agnostic – works across mixed endian and mixed mode (32 bit and 64 bit)
Types of RMD Calls
- Sync (with or without Response)
- This call will block until a response is received
- Reliable- function caller knows whether or not it succeeded when the call returns
- Async with Response
- This will initiate the function call and include a callback function to handle the response
- Reliable – function caller knows whether or not it succeeded via the callback
- Async without Response
- This sends NULL for callback function
- Not reliable
RMD Usage
From the caller’s perspective, RMD usage is essentially a function call if IDL was used to generate the client/server stubs. RMD functions can be defined, and code generated through the OpenClovis IDE; please refer to the OpenClovis IDE User’s Guide chapter ‘Defining IDL’
Underneath the IDL are calls to the RMD API which are rarely used directly but described here for completeness.
Irrespective of the type of the call the RMD API will require at least the following parameters:
- IOC address (destination address and port)
- Input message (Input arguments to the call)
- Output message (The returned arguments)
- flags
- RMD options
Additionally, in case of async call, a callback function and a cookie (piece of context data that is not used by RMD, but passed back to the callback) need to be passed.
As illustrated in the diagram below the address comprises of the node address and port on which the application/service provider is listening. The user is also required to specify the service he wants executed via a RMD number which comprises of the Client ID and Service ID. The former helps identify which client service is sought – this could be the native table which consists of the services exposed by the application or any other client table installed by the libraries to which the application is linked. The service number is the index of the service that is desired.
RMD Addressing
For further details on the RMD usage kindly refer OpenClovis API Reference Guide.
RMD IDL
RMD is typically used via IDL so that the user is saved from the idiosyncrasies of the underlying architectures and such.
- RMDIDL simplifies building of RMDs
- Generates server and client stubs
- Stubs do marshalling and un-marshalling of arguments making them platform agnostic
- Select appropriate semantics
- Takes care of endianness and mixed mode issues
- Uses XDR (see internet RFC1014) notation
- OpenClovis/IDE enables the generation of RMDs and linking them to a client EO
- Any function installed in an EO client can be called remotely
RMD EO Interface
RMD and EO are tightly knit as can be observed in the illustration above. The service provider or server exposes a certain set of services by installing it in the EO. The client application interested in the service makes a RMD call to the server with the desired arguments. The node address specifies the node on which the server resides and the port identifies the server process. The RMD number specifies the service that needs to be executed of a particular client residing on the server. This request is sent across over TIPC/IOC layer to the server. The receiver thread of the server picks up this request and queues the same into the EO job queue and wakes up one of the worker threads to process the request. The worker thread checks the service requested and processes the request in the context of the server. The client is totally unaware where the service is processed. It could be in the same process address space, on a process on the same node or a process on a remote node.
Conclusion
RMD is an excellent approach to make RPC calls. It runs on the top of OpenClovis SAFplus middleware: if you want to use it, you must install the OpenClovis SAFplus SDK, follow the tutorial at chapter 11: Defining IDL of https://help.openclovis.com/index.php/Doc:latest/ideguide
Other support, please send email to support@openclovis.org.