The run-time connection between NeXtMidas macros running on (possibly) different platforms is provided by Remote Midas InterFace (RMIF), which is a protocol based conceptually on Java's Remote Method Invocation (RMI) facility. RMI makes objects at a remote site accessible as if they were local objects. An RMIF object is defined by a node name (or network address) and a port number.
RMIF-based transactions are critical to create distributed signal processing
applications. The sd360 macro that is included in the NeXtMidas baseline
(./nxm/sys/mcr/sd360.mm
) provides an example of RMIF usage and the
client/server division of labor within NeXtMidas. (See X-Midas RMIF for details on how to setup RMIF on
X-Midas).
The RMIF protocol allows NeXtMidas GUIs to control Midas applications running on remote platforms. Although the protocol can be used for other purposes, its primary design goal is to minimize link bandwidth for data displays and to respond robustly to the network drop-outs that are common to real-world, long-distance multihop links.
The current implementation of RMIF is layered on top of UDP (User Datagram Protocol) for the data portion of communication and a customized RDP (Reliable Datagram Protocol) for command and status transfer. All data routing to and from remote objects is handled by the UDP header. A benefit of UDP is packet throughput. By combining the reliable and unreliable streams in the same socket, you can implement priority schemes that, for example, favor controls over data. Another benefit of UDP is its connectionless. Since there never is a connection, network problems cannot cause connections to hang in an unknown state.
The UDP payload begins with an 8-byte RMIF header. The RMIF protocol uses the 8-byte header to compress the overhead that is necessary to serialize a method call. The header, protocol and functions are described in detail RMIF API .
The RMI-like components of the protocol are accomplished with the GET, RET, SET, and ACK functions. The Java language suggests using public methods beginning with "set" and "get" to provide a common interface to an object's public properties. To allow combining multiple SETs or GETs into a single network packet, the data portion of the GET|RET|SET|ACK packet is a serialized table class. The key for each table entry is the body of the method name, and the value for each key is the method's argument. For example, to call the setFreq, setAmp, and setOptions methods on a remote object the data portion of a RMIF packet with the FUNC=SET would be:
{FREQ=1.3E6,AMP=1,OPTIONS={MODE=1,AXIS=NONE}}
The syntax is all ASCII which allows off-the-shelf tools or XML parsers to monitor network traffic. Notice that the setOptions() method has more than one argument. To do this, the arguments are expressed as another table, with each argument being named. This helps monitoring/debugging.