APIs via IPC - Balance Speed vs. Scalability (2)
Implementing the API using IPC gives more options in terms of scaling at the cost of additional runtime compared to a direct call.
An example for scaling made possible via IPC: Separate inner control loop from log functions.
Create a server process to log data received at a data mailbox. The hot part of your control loop would periodically sample I/O, apply the control algorithm on the input, generate output to the I/O and finally send a log message for diagnostics to the data mailbox of the server process.
Initially there may be enough time to run the log-server on the same node as the control loop driving its special I/O. Should your control algorithm get more complex and use more time or you need a faster cycle-time, the node may run out of cycles to execute the log server on this node. In such situations, you can load the server process on another node. Your inner loop can use more cycles on the existing node with the I/O, by using a data mailbox you do not need to change your control loop.
INtime’s global object technology allows transparent access to IPC objects regardless of which node they are implemented. Detailed explanation on INtime’s global object technology, including the additional discovery required to allow transparent re-hosting of the API, is found in the training.
The delay imposed by IPC to global objects depends how “close” the server is to the client and how fast it runs. Client and server running on one node see less delay compared to running on different nodes on one host or even running on different hosts connected by an Ethernet cable.