Remote Procedure Calls (RPC)
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.
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).