What is the point of LRPC? Why would anyone want to make Remote Procedure Calls to the same machine?

Question

From what I understand about RPC (Remote Procedure Calls), is that they provide a way to send function calls, invocations, etc to remote machines. The obvious advantage of this is that you can have a single program that runs on a cluster of machines and can handle more requests, more data, on so on.

But I'm puzzled by LRPC - Lightweight RPC. Apparently this stuff exists to speed up RPC on the same machine. As written in the paper I linked to:

Lightweight Remote Procedure Call (LRPC) is a communication facility designed and optimized for communication between protection domains on the same machine. In contemporary small-kernel operating systems, existing RPC systems incur an unnecessarily high cost when used for the type of communication that predominates-between protection domains on the same machine. This cost leads system designers to coalesce weakly related subsystems into the same protection domain, trading safety for performance. By reducing the overhead of same-machine communication, LRPC encourages both safety and performance.

My question is: what is the point of RPC if you're running everything o nthe same computer. The R stands for REMOTE. If you're not gonna be Remote, then just call it LPC. What am I missing?

Answer 1

There are several use cases for local RPC, but a very straightforward example is when a server has both remote and local clients.

Let us consider for example an RPC-based print server:

• You may have clients located on remote hosts (e.g. for a networked/sharing print server);
• You may also have also clients located on the server's host itself (so that local applications can print too).

Obviously, you don't want to write both an print-server for remote clients and a separate print-server for local clients. Thus, it is far better if the architecture or middleware allows for designing a print server that can be used indifferently by remote clients (remote RPC) and local clients (local RPC).

At this point, the architecture or middleware ensures a common interface both for local clients and for remote clients: how inter-process communication is achieved in practice must be made fully transparent to the application developer.

However, using the same inter-process communication technology both for remote clients and for local clients may be inefficient. Thus, it is fairly common for the RPC architecture to implement some kind of optimization so as to optimize performance when the server and the client are located on the same host. In spirit, this optimization is very similar to the fact that local network communication use the local loop rather than going back and forth between the host and the network card.

Lightweight RPC is one such solution (it is not the only one) allowing for optimizing RPC performance for local clients. When this optimization is implemented into the RPC architecture:

• The same RPC interface can be made available both for local and for remote clients:
• Application developers do not have to handle the issue that some clients may be local when other clients may be remote;
• The RPC architecture optimizes under the hood calls to local servers, so that local clients are not penalized by some remote IPC technique that would be sub-optimal for local communication.