Birrell, Nelson, and Remote Procedure Call: Making Network Services Look Local
Remote Procedure Call replaced much hand-written message exchange with interface-defined calls, generated stubs and binding, while forcing programmers to confront the failures that distinguish a network call from a local one.
Distributed programs needed a simpler abstraction than hand-built messages
Early networked programs often communicated by explicitly constructing packets, sending them, waiting for replies and decoding the results. Bruce Nelson’s 1981 Stanford dissertation and Xerox PARC report framed remote procedure call as a way to raise that interaction to the level of ordinary programming-language procedure invocation.[3]
The central idea was deliberately familiar: a program should call a procedure defined by an interface, while generated or library code handles the network exchange. The remote boundary would not disappear, but programmers could express service interactions using a structure already common in local software.
Birrell and Nelson turned the idea into an engineering system
Andrew Birrell and Bruce Nelson’s 1984 paper described the Cedar RPC package, including binding, transport, generated stubs, failure handling and performance measurements.[1] The paper became a canonical account because it treated RPC not only as syntax sugar but as an end-to-end systems problem.
The implementation had to find a server, marshal arguments, transmit a request, execute code remotely, return results and map failures back into the caller’s programming model.
Stub generation moved protocol boilerplate into tools
Interface descriptions could be used to generate client and server stubs that encoded and decoded arguments. This reduced repetitive hand-written networking code and made the interface definition a durable contract between separately compiled components.
Binding became the distributed equivalent of linking
A local procedure call relies on a linker and an address inside one process. RPC needed a way to discover which machine and process currently provided the requested service. The Cedar system therefore treated binding as a major part of the design.[1]
This distinction survives in later service discovery systems. A caller wants a stable service name, while the implementation may move, restart or scale across many machines.
Location transparency was useful but never complete
RPC can make the call site look familiar, but it cannot make a network call have the same physics as a local call. Latency, partial failure, authentication and retries remain observable even when the syntax resembles an ordinary function invocation.
Sun RPC carried the model into open network services
Sun Microsystems standardized a widely deployed RPC message protocol as part of its Open Network Computing environment. RFC 1057 describes programs, versions, procedures, transaction identifiers and XDR-encoded messages, along with the important distinction between local and remote failure behavior.[2]
Sun’s design made RPC a reusable substrate rather than a feature tied to one application. Network services could define procedure sets while relying on a common call and reply format.
XDR separated data representation from machine architecture
Remote calls cross machines that may differ in byte order, word size and operating-system conventions. Sun RPC paired the call model with External Data Representation so arguments had a portable wire encoding instead of inheriting one machine’s memory layout.[2]
NFS demonstrated what RPC looked like at system scale
Sun’s Network File System was built on RPC and XDR. The original NFS implementation paper explains that the protocol used RPC to simplify definition, implementation and maintenance while exposing remote file operations transparently to applications.[4]
NFS made RPC concrete for a large audience: operations such as lookup, read and write were network procedures, and a distributed filesystem could be specified as a service interface rather than a custom stream of ad hoc packets.
Idempotence became a practical design tool
When a client times out, it may not know whether the remote operation failed or the reply was merely lost. Protocol designers therefore care about whether repeating an operation is safe, and RPC systems often need transaction identifiers, duplicate suppression or application-specific retry rules.
Remote calls exposed the problem of ambiguous failure
RFC 1057 explicitly notes that remote procedure calls differ from local calls because servers and networks can fail independently.[2] A missing reply can mean the request never arrived, the server crashed before executing it, the server executed it but the reply vanished, or the client lost connectivity afterward.
This ambiguity is one of RPC’s most important historical lessons. A convenient interface does not repeal distributed-systems failure modes; it concentrates them at a boundary that application designers must understand.
The ONC RPC protocol outlived its original Sun environment
RFC 5531 standardized the deployed ONC RPC version 2 protocol in 2009 and still cites Birrell and Nelson as foundational background.[5] The continuity shows how durable the procedure-call abstraction became even as implementations, transports and security mechanisms changed.
Modern RPC frameworks use different interface languages and transports, but they retain recognizable pieces: schema-defined methods, generated code, service discovery, serialization, deadlines, retries and explicit error models.
Why RPC belongs in distributed-systems history
Nelson’s early work and the Birrell–Nelson Cedar system turned network communication into an interface-oriented programming model.[3][1] Sun RPC then made that model an interoperable protocol and NFS demonstrated it in a major distributed service.[2][4]
The later ONC standard confirms the abstraction’s staying power.[5] RPC’s lasting contribution is not the claim that remote calls are truly local; it is the disciplined separation of application interfaces from the machinery of addressing, serialization, transmission and reply handling.
Works Cited
- 01
- 02
- 03Computer History Museum Software Preservation Group — Mesa History Collection, Bruce Nelson RPC thesis record softwarepreservation.computerhistory.org
- 04
- 05
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead