Remote Procedure Calls (RPC)

• Midas Doc
• Feature Listing
• Application Listing
• Online Database
• FAQ
• Index

RPC in a nutshell

Midas uses a Remote Procedure Call (RPC) system to allow different midas clients to talk to each other directly. One client can issue a command to another, and the second client will perform some action and send a response back to the caller.

Internal usage in midas

Internally, midas uses the RPC system to handle run transitions, ODB hotlinks and more.

For example, if you start a run using the web interface, mhttpd (the webserver) will send an RPC_RC_TRANSITION message to clients that want to handle the begin-of-run transition. Each client responds with whether it's okay for the transition to proceed.

Any clients that are running on a remote server use RPC for all their communications with midas. The special mserver program (running on the main host) is responsible for handling these requests. For example, whereas a local client can read an ODB value directly from shared memory on the main host; a remote client instead issues an RPC call to mserver, which reads the value from shared memory and returns it to the caller.

At the very lowest level, each program checks if it has any outstanding RPC requests to handle as part of the cm_yield() function, which should be called periodically by every midas client.

Use in user code - JRPC

One of the RPC commands, RPC_JRPC, is very flexible and allows the user to easily integrate custom commands into their programs. There are interfaces in C++, python and javascript.

The calling code specifies:

• The program it wants to talk to
• The command it wants to issue (generally a short string)
• Some arguments (either plain text or JSON)

The client then:

• Decides what to do based on the command and arguments
• Responds with a status code and text message (either plain text or JSON)

Some example uses of this system are:

• Have a client turn some equipment off when the user clicks a button on a webpage.
• Offload some complex calculations to another program (e.g. if your main client is in C++ but it's much easier to implement the calculations in python).
• Implement a web-based plot display that gets data as JSON from a python/C++ client
• ...

Benefits vs ODB hotlinks

Often users implement inter-process communication using ODB hotlinks (where a client can say "tell me whenever /Path/to/something in the ODB changes"). Although this works for simple cases, the JRPC system is much more flexible and robust.

• Much easier to specify arguments. Avoids race conditions if you were to use multiple ODB keys to tell the target what to do.
• There is no "competition" for the ODB key(s). Multiple clients can call the same RPC without interfering with each other.
• More flexible response format as you can return a (very) long string. Alternatives would be to put the response in an ODB value (limited maximum length) or in a file on disk (extra overhead, and possibly annoying to deal with stale files over NFS).