Skip to content

Remote Procedure Call

A declared procedure invocation across an execution-context boundary, with target binding, argument transfer, remote dispatch, and an explicit result-or-failure contract.

Version
v1 · 2026-10-17 · History
Domain-specific #
14275
Domain group
Applied Sciences & Engineering
Origin domain
Computer Science & Software Engineering
Subdomain
Distributed Computing → Computer Science & Software Engineering
Aliases
RPC

Core Idea

A remote procedure call (RPC) invokes a declared operation implemented in another execution context. The caller identifies an operation and supplies arguments; a binding and transfer path carries a representation of that call to the callee; the callee dispatches the operation. The implementation's result and failure rules determine what the caller may infer afterward. This is a procedure invocation across a context boundary, rather than an arbitrary message sent to an address.[1][2]

The boundary need not be between physical machines. Birrell and Nelson's Cedar implementation uses caller and callee machines, while IBM's DCE Greet tutorial runs distinct client and server programs on the same OS/390 machine.[1][2] The usual local-call analogy helps express the invocation, but it does not remove transport delay, independent failures, or uncertainty after a missing reply. Nor does the mechanism require generated stubs, one blocking call, one reply, or exactly-once execution in every system.[1][3]

Structural Signature

Sig role-phrases: declared callable operation; execution-context boundary; target binding and transferable call; remote dispatch; contract-specific outcome and failure.

  • Declared callable operation. The caller and callee agree on an operation and interpretable arguments. Without that callable contract, an addressed exchange may be messaging, but it has not been identified as this procedure invocation.[1][2]
  • Execution-context boundary. The implementation runs in a separate context from the caller. The separation may be between processes on one machine or across machines; a direct in-context function call lacks this boundary.[1][2]
  • Target binding and transferable call. A path associates the operation with a reachable implementation and carries its identifier and arguments across the boundary. Cedar's Grapevine binding, DCE's string binding, and ONC's program numbers are particular realizations, not one required format.[1][2][4]
  • Remote dispatch. The callee selects and runs the declared operation. Transporting bytes without selecting a procedure is insufficient.[1][2]
  • Outcome and failure contract. The chosen implementation says what return, status, exception, silence, or a permitted no-reply mode lets the caller infer. The role is a specified interpretation, not a universal promise of one response or exactly-once execution.[1][3]

What It Is Not

  • Not every local-looking call. Local syntax is a design choice. A call wholly inside one execution context does not need remote binding, transfer, or distributed failure handling.[1]
  • Not a synonym for any network message. A message protocol can carry other interactions; RPC additionally needs a declared operation that the callee dispatches. RFC 5531 makes this distinction even for its own message-passing protocol.[3]
  • Not necessarily a remote object. Remote object invocation may use RPC, but a procedural call such as DCE Greet does not need persistent remote object identity or a transferable object reference.[2]
  • Not always request–one-reply. ONC RPC describes batch calls for which no reply is sent and broadcast calls that may receive multiple replies. A one-reply example cannot define the whole class.[3]
  • Not a guarantee of exactly-once execution. Cedar gives its own successful-return guarantee while acknowledging uncertainty after an exception. ONC's transaction identifiers can aid duplicate suppression, but no reply cannot prove nonexecution even over a reliable transport.[1][3]

Scope of Application

RPC applies where software invokes a named or declared operation across a separate execution context by binding a target, transferring a call, and dispatching it under known outcome rules. Cedar's implemented research runtime, IBM's OS/390 DCE tutorial, and Oracle's ONC rpcgen code illustrate different toolchains inside that scope. The original DCE/RPC member is one implementation family of this wider mechanism; its IDL and generated stubs do not define every RPC.[1][2][4]

The evidence grades differ. Birrell and Nelson report a fully implemented package in use by Cedar programmers, including Alpine file-server communication, while noting that named projects had not reached full-scale use. IBM publishes a complete runnable Greet tutorial and illustrative output, not an independently observed production deployment. Oracle supplies a third first-party worked-code check, rather than a separately observed deployment. The cited ONC RFC defines one protocol version and exception modes, not all RPC systems.[1][2][4][3]

Clarity

First ask what operation is being invoked. A procedure name, argument contract, and callee-side implementation distinguish an invocation from generic addressed data. Next ask which context executes it. Distinct same-machine processes can meet this test; physical distance is not the criterion. Then trace how the caller binds the target and how the callee dispatches it.[1][2]

Finally ask what a result or absence of one means in this contract. Cedar correlates result and call identifiers, suppresses duplicate call packets, and says a returning call entails one server invocation; after an exception the caller may not know whether invocation happened once or not at all. RFC 5531 leaves execution semantics to the transport and implementation: its transaction identifier can support limited duplicate suppression, but silence does not establish that an operation never ran.[1][3] These are bounded contracts, not interchangeable guarantees.

Manages Complexity

The RPC model lets application code reason in terms of an operation and arguments while the implementation handles representation, transport, binding, dispatch, and reply correlation. Cedar uses Mesa interfaces, generated Lupine stubs and Grapevine-resolved exports. Greet uses DCE IDL, generated stubs, a string binding and a listening server. Those details differ, yet the five roles allow the two paths to be compared without mistaking one vendor's tools for the definition.[1][2]

Compression can conceal real costs. A local-looking call still crosses an independently failing context, and retrying after silence can repeat an effect. Good use of the abstraction keeps the selected implementation's failure and completion rules beside the call interface instead of assuming ordinary local-return behavior.[1][3]

Abstract Reasoning

To classify a candidate, identify the callable contract and the separate callee context. Trace operation declaration → target binding → argument representation and transfer → callee dispatch → outcome interpretation. If the path stops at message delivery without a declared operation being run, it is not this whole mechanism. If it remains inside one context, it is a local call.[1][2]

To reason about a failed call, avoid inferring nonexecution from a missing result. Ask which stage could have failed, whether the runtime correlates and suppresses repeated calls, and which outcome the caller can distinguish. Cedar's call identifiers and ONC's transaction identifiers serve related purposes, but their guarantees are contract-specific. A batch call with no reply and a broadcast call with several replies still require a declared remote operation and dispatch before they count as RPC instances.[1][3]

Knowledge Transfer

The five-role diagnostic transfers among RPC implementations without importing their syntax. Cedar's Mesa interface and Grapevine binding can be replaced by Greet's IDL and string binding, or by the program/version/procedure contract in Oracle's ONC example. The shared inference is about cross-context invocation, not identical wire encodings, stub generators, failure guarantees, or numbers of replies.[1][2][4][3]

The word call also travels into ordinary conversation and other institutions. That vocabulary alone does not reveal a computational callee, a transferable argument representation, or distributed completion semantics. A claimed new setting must map those roles literally before knowledge about RPC failure or retry can be transferred.

Examples

Canonical: Cedar RPC with Alpine FileAccess

Birrell and Nelson describe a Cedar package whose user calls a user stub; Lupine generates the stub from a Mesa interface. RPCRuntime transfers the call to a callee machine, where a server stub invokes server code. Their binding discussion uses the FileAccess.Alpine interface and Grapevine-resolved interface type and instance; their status section reports real Cedar programmer use, including Alpine communication, while explicitly withholding a full-scale-use claim.[1]

Mapped back: declared operation = Mesa interface procedure and argument/result types; boundary = caller and callee machines; binding and transfer = Grapevine-resolved export, stubs, and RPCRuntime packets; dispatch = server runtime and stub invoke server code; outcome = correlated result identifier plus Cedar's documented duplicate and exception rules.

This is an implemented research-system case, not proof that every RPC uses generated stubs or Cedar's successful-return semantics.

Applied/practice: IBM OS/390 DCE Greet

IBM's runnable Greet tutorial declares greet_rpc in IDL with a binding handle, input greeting, and output reply. It supplies separate client and server programs on the same machine. The server manager implements the procedure and the server prints UDP and TCP bindings; the client starts with a protocol sequence, host address and endpoint. IBM shows the expected client reply and server receipt as illustrative tutorial output.[2]

Mapped back: declared operation = greet_rpc and its IDL parameters; boundary = separate same-machine client/server programs; binding and transfer = DCE-generated stubs and the passed string-binding components; dispatch = listening server and manager routine; outcome = reply written to the output argument and sample client/server output.

The case demonstrates a complete DCE/RPC instance without claiming an independently witnessed deployment, physical machine separation, or a universal one-reply rule.

Structural Tensions

T1: Local-call familiarity versus distributed-failure visibility. A familiar procedure interface makes cross-context invocation easier to use, but hiding the boundary can invite a false inference that a missing reply means no execution. Lean toward local-call simplicity and callers may overlook independent failure; lean toward explicit statuses and boundary rules and callers must handle more policy and interface detail. Diagnostic: Which outcomes must this caller distinguish before retrying or declaring completion?[1][3]

T2: Stronger duplicate control versus communication and state cost. Retaining call identity and tracking retransmissions can improve an implementation's duplicate handling, while lighter exchanges avoid some bookkeeping. Lean toward stronger tracking and the runtime must maintain state and do more work; lean toward low overhead and an application may have to accept weaker inference or manage duplicate effects itself. Neither side eliminates uncertain failures. Diagnostic: What repeated effect would justify the extra identity and retry bookkeeping for this operation?[1][3]

Structural–Framed Character

Spectrum and evaluation. RPC is predominantly structural within distributed computing: a declared call crosses a context boundary, binds a target and dispatches an operation. Transparency and speed are design aims, not identity conditions. A slow RPC or one with visibly remote syntax is still an RPC if the mechanism's roles are present.[1]

Human practice and institutional origin. Programmers choose callable contracts, bindings and retry policies, so human choices shape each instance. Cedar, DCE and ONC arose from different toolchains and institutions; no one institution's IDL, stub generator or protocol number is constitutive. Once a contract is defined, the call path and outcome limits can be inspected without relying on how its author markets the system.[1][2][4]

Vocabulary travel and import versus recognition. Call, request and Interface appear in many fields. Using those words for a legal request or conversation imports a computing metaphor; it does not reveal remote procedure dispatch. Literal recognition needs the execution-context, binding, transfer, dispatch and outcome roles. The broad idea of a declared operation crossing a boundary does not itself carry RPC’s software binding, remote dispatch, and distributed failure semantics into other domains. The cited systems establish that fuller mechanism within computing.[3]

Its character: a domain-specific structural software mechanism, framed by each implementation's binding and failure contract rather than by one vendor's syntax or a claim of universal transparency.

Structural Core vs. Domain Accent

The skeleton is a declared operation invoked across a boundary through a binding and transferable call, followed by dispatch and outcome interpretation. That relation explains what persists between Cedar and Greet. The domain mechanism is concrete software: separate execution contexts, argument representation, runtime delivery and partial-failure rules. These are necessary to the named RPC whole, not decorative terminology.[1][2]

Grapevine, Lupine, DCE IDL, DCE string bindings and ONC rpcgen are accents that fill the roles differently. The two whole cases remain inside distributed computing. Their shared binding, dispatch, and outcome roles make RPC a domain-specific software mechanism; a verbal analogy to requests in another field does not supply those roles.

This entry is part of Interface.

The Interface Prime illuminates the declared operation contract; Message Passing concerns addressed exchanges that may carry a call. Neither alone supplies the complete RPC sequence. Inter-process Communication is a broader neighboring mechanism for data exchange between distinct processes. RPC uses such exchange to invoke a declared procedure through binding, argument transfer, remote dispatch, and outcome handling; communication alone need not be a procedure call.

Function Call supplies the callable-unit analogy, yet a local function call lacks the necessary cross-context path. Request–Response is narrower on paired reply shape than ONC's documented batch and broadcast modes. Distributed Object adds object identity and transferable reference roles absent from the procedural Greet example.[2][3]

Relationships to Other Abstractions

Local relationship map for Remote Procedure CallParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Remote Procedure CallDOMAINPrime abstraction: Interface — is part ofInterfacePRIME

Current abstraction Remote Procedure Call Domain-specific

Parents (1) — more general patterns this builds on

  • Remote Procedure Call is part of Interface Prime

    Every RPC contains a declared caller-to-callee operation interface governing arguments, binding, dispatch, and outcome interpretation.

Hierarchy path (1) — routes to 1 parentless root

Neighborhood in Abstraction Space

Remote Procedure Call sits in a moderately populated region (52nd percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.

Family — Software & Systems Architecture (32 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-17

Not to Be Confused With

  • A local function call: it can share operation and arguments but has no cross-context binding or distributed outcome boundary.
  • A generic request or message: addressed data alone does not show declared procedure dispatch.[3]
  • A DCE product feature: DCE/RPC is one full instance; the named mechanism also appears in Cedar and ONC forms.[1][2][4]
  • A distributed object: remote object identity and transferable references add requirements that a procedural RPC need not meet.
  • An exactly-once guarantee: successful-return and retry behavior depend on the selected implementation, transport and failure state.[1][3]

References

[1] Andrew D. Birrell and Bruce Jay Nelson, “Implementing Remote Procedure Calls,” ACM Transactions on Computer Systems 2, no. 1 (February 1984), 39–59. Complete original paper at an institutional mirror; consulted §§1.3–1.5 (PDF zero-based pp. 2–5), §2 (pp. 6–8), §3.1–3.2 (pp. 10–12), and §5 (p. 19). Cedar package implementation/use is reported, but Alpine had not reached full-scale use. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s ↩t ↩u ↩v ↩w ↩x ↩y ↩z ↩27

[2] IBM, OS/390 DCE Application Development Guide: Introduction and Style, fourth edition (September 1998), SC28-1587-03. Complete first-party manual; consulted “Creating a Sample Application: GREET,” printed pp. 58–74/PDF zero-based pp. 87–103, especially Figs. 41, 46 and 53–60. The supplied code and shown outputs are tutorial material, not independent observation of production deployment. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r

[3] R. Thurlow, “RPC: Remote Procedure Call Protocol Specification Version 2,” RFC 5531 (May 2009), DOI 10.17487/RFC5531. Official protocol specification; consulted §4 RPC Model, §5 Transports and Semantics, and §§8.4.1–8.4.2 batch and broadcast. Its transaction-ID and failure statements are ONC-specific; it does not promise universal exactly-once execution. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p

[4] Oracle, ONC+ RPC Developer's Guide: rpcgen Tutorial (updated March 2019), “Converting Local Procedures to Remote Procedures,” Examples 1–3 and generated-file discussion. Complete first-party worked code, not a reviewer-executed deployment. registry ↩a ↩b ↩c ↩d ↩e ↩f