§48.5–48.6Remote Procedure Call (RPC) and Summary

Distributed shared memory failed; the abstraction that won comes from programming languages, not the OS.

48.5 Remote Procedure Call (RPC)

A remote procedure call remote procedure call RPC: the dominant abstraction for building distributed systems, borrowed from programming languages. It makes executing a routine on a remote machine look almost like an ordinary local function call — the client calls a stub, and the RPC system hides the messaging, argument marshaling, and timeout/retry needed to run the code remotely and return the result. defined in ch. 48 — open in glossary (RPC) has one goal: make running code on a remote machine as simple as calling a local function. The server exports some routines; the client calls them; the RPC system handles all the messaging magic in between. That magic has two pieces: a stub generator and a run-time library.

The stub generator

The stub generator stub generator The RPC 'protocol compiler' that takes an interface definition and generates the glue code: a client stub (which marshals the arguments into a message, sends it, waits, and unmarshals the reply) and a server stub (which unmarshals the request, calls the real function, and marshals the reply). Automating this removes a class of hand-written packing bugs and can optimize the code. defined in ch. 48 — open in glossary (or protocol compiler) takes an interface — the calls the server wants to export — and generates the glue code so nobody has to write fragile message-packing by hand:

The heart of a stub is marshaling marshaling Packing a function's arguments (or results) into a single contiguous message buffer so they can be sent across the network — also called serialization. The inverse operation at the far end, extracting the values back out of the message, is called unmarshaling or deserialization. defined in ch. 48 — open in glossary — packing the function id and arguments into one contiguous message buffer (a.k.a. serialization); the far side unmarshals (deserializes) them back out:

Put the pieces in motion and a whole remote call looks like this:

Two wrinkles the stub compiler must handle: complex arguments — a raw pointer (as in write(fd, buf, size)) means nothing on another machine, so RPC uses well-known types (e.g. a buffer_t of a given size) or annotations to know which bytes to serialize — and server concurrency: a server that handles one request at a time wastes resources whenever a call blocks, so real servers use a thread pool, dispatching each request to a worker (paying the usual cost of locks and synchronization).

The run-time library

The run-time library does the heavy lifting — performance and reliability. A few of its jobs:

• Naming. The client must find the service — commonly by hostname/IP + port number (and, above that, DNS). Full naming is a deep topic of its own.
• Transport choice. Reliable TCP seems the obvious pick, but it’s usually the wrong one:

• Long-running calls. A slow remote call can look like a failure and trigger a needless retry; the run-time can send an explicit ack and let the client periodically ask “still working?”.
• Large arguments. Bigger than one packet? The run-time fragments on the sender and reassembles on the receiver.
• Byte order. Machines differ (big- vs little-endian), so RPC defines a canonical wire format — Sun RPC’s XDR (eXternal Data Representation) — and converts when a machine’s native order differs.
• Asynchrony. Normally an RPC is synchronous (the client waits). An asynchronous RPC returns immediately so the client can do other work, then later collects the result — overlapping computation with communication.

48.6 Summary

Distributed systems introduce one dominant new problem — failure, now a commonplace event (“with thousands of machines, failure is happening all the time”). Their heart is communication, and its most common abstraction is RPC, which hides timeout/retry, acknowledgments, marshaling, and byte-order details behind something that closely mirrors a local procedure call. The best way to really get it is to use one: Sun’s rpcgen, or modern takes like Google’s gRPC and Apache Thrift. Next, we’ll see these ideas made concrete in two real distributed file systems — NFS and AFS.