A Remote Function Call Will Never Really Be Local: Rethinking Distributed Computing #4

The promise of Remote Procedure Call (RPC) is to allow a client to call a procedure on another machine as if it were calling a local procedure. However, RPC has its limitations and cannot truly erase the distance between the client and server. The network does not understand functions; it understands messages and bytes. RPC must transform the procedure call into communication, which involves several steps.

First, the application code calls a client stub, which builds a message and passes it to the communication middleware. The message crosses the network, and upon reaching the server, the middleware passes it to a server stub or skeleton. The server stub reconstructs the arguments and calls the real local implementation. Finally, the result is sent back through the reverse process.

RPC relies on agreed-upon representations for parameters and results, as different machines may have different byte orders, encoding rules, floating-point representations, and memory layouts. This means that the data most definitely knows it has traveled, and the illusion of a local call begins to fall apart.

In addition, remote invocation requires binding, where the client must discover and connect to the service implementing the desired interface. This is where location transparency comes into play, but the underlying machinery still exists. Local calls have a comfortable timeline, with the client waiting for the procedure to return before continuing. RPC can reproduce this model, but other interaction patterns become useful, such as sending a message and waiting for a response without waiting for a direct return.