Hubbry Logo
Remote procedure callRemote procedure callMain
Open search
Remote procedure call
Community hub
Remote procedure call
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Remote procedure call
Remote procedure call
Remote procedure call
View on Wikipedia
from Wikipedia

In distributed computing, a remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to execute in a different address space of the current process (commonly on another computer on a shared computer network), which is written as if it were a normal (local) procedure call, without the programmer explicitly writing the details for the remote interaction. That is, the programmer writes essentially the same code whether the subroutine is local to the executing program, or remote. This is a form of server interaction (caller is client, executor is server), typically implemented via a request–response message passing system. In the object-oriented programming paradigm, RPCs are represented by remote method invocation (RMI). The RPC model implies a level of location transparency, namely that calling procedures are largely the same whether they are local or remote, but usually, they are not identical, so local calls can be distinguished from remote calls. Remote calls are usually orders of magnitude slower and less reliable than local calls, so distinguishing them is important.

RPCs are a form of inter-process communication (IPC), in that different processes have different address spaces: if on the same host machine, they have distinct virtual address spaces, even though the physical address space is the same; while if they are on different hosts, the physical address space is also different. Many different (often incompatible) technologies have been used to implement the concept. Modern RPC frameworks, such as gRPC and Apache Thrift, enhance the basic RPC model by using efficient binary serialization (e.g., Protocol Buffers), HTTP/2 multiplexing, and built-in support for features such as authentication, load balancing, streaming, and error handling, making them well-suited for building scalable microservices and enabling language interoperability.[1]

History and origins

[edit]

Request–response protocols date to early distributed computing in the late 1960s, theoretical proposals of remote procedure calls as the model of network operations date to the 1970s, and practical implementations date to the early 1980s. Bruce Jay Nelson is generally credited with coining the term "remote procedure call" in 1981.[2]

Remote procedure calls used in modern operating systems trace their roots back to the RC 4000 multiprogramming system,[3] which used a request-response communication protocol for process synchronization.[4] The idea of treating network operations as remote procedure calls goes back at least to the 1970s in early ARPANET documents.[5] In 1978, Per Brinch Hansen proposed Distributed Processes, a language for distributed computing based on "external requests" consisting of procedure calls between processes.[6]

One of the earliest practical implementations was in 1982 by Brian Randell and colleagues for their Newcastle Connection between UNIX machines.[7] This was soon followed by "Lupine" by Andrew Birrell and Bruce Nelson in the Cedar environment at Xerox PARC.[8][9][10] Lupine automatically generated stubs, providing type-safe bindings, and used an efficient protocol for communication.[9] One of the first business uses of RPC was by Xerox under the name "Courier" in 1981. The first popular implementation of RPC on Unix was Sun's RPC (now called ONC RPC), used as the basis for Network File System (NFS).

In the 1990s, with the popularity of object-oriented programming, an alternative model of remote method invocation (RMI) was widely implemented, such as in Common Object Request Broker Architecture (CORBA, 1991) and Java remote method invocation. RMIs, in turn, fell in popularity with the rise of the internet, particularly in the 2000s.

Message passing

[edit]

RPC is a request–response protocol. An RPC is initiated by the client, which sends a request message to a known remote server to execute a specified procedure with supplied parameters. The remote server sends a response to the client, and the application continues its process. While the server is processing the call, the client is blocked (it waits until the server has finished processing before resuming execution), unless the client sends an asynchronous request to the server, such as an XMLHttpRequest. There are many variations and subtleties in various implementations, resulting in a variety of different (incompatible) RPC protocols.

An important difference between remote procedure calls and local calls is that remote calls can fail because of unpredictable network problems. Also, callers generally must deal with such failures without knowing whether the remote procedure was actually invoked. Idempotent procedures (those that have no additional effects if called more than once) are easily handled, but enough difficulties remain that code to call remote procedures is often confined to carefully written low-level subsystems.

Sequence of events

[edit]
  1. The client calls the client stub. The call is a local procedure call, with parameters pushed on to the stack in the normal way.
  2. The client stub packs the parameters into a message and makes a system call to send the message. Packing the parameters is called marshalling.
  3. The client's local operating system sends the message from the client machine to the server machine.
  4. The local operating system on the server machine passes the incoming packets to the server stub.
  5. The server stub unpacks the parameters from the message. Unpacking the parameters is called unmarshalling.
  6. Finally, the server stub calls the server procedure. The reply traces the same steps in the reverse direction.

Standard contact mechanisms

[edit]

To let different clients access servers, a number of standardized RPC systems have been created. Most of these use an interface description language (IDL) to let various platforms call the RPC. The IDL files can then be used to generate code to interface between the client and servers.

Analogues

[edit]

Notable RPC implementations and analogues include:

Language-specific

[edit]
  • Java's Java Remote Method Invocation (Java RMI) API provides similar functionality to standard Unix RPC methods.
  • Go provides a package rpc for implementing RPC, with support for asynchronous calls.
  • Modula-3's network objects, which were the basis for Java's RMI[11]
  • RPyC implements RPC mechanisms in Python, with support for asynchronous calls.
  • Distributed Ruby (DRb) allows Ruby programs to communicate with each other on the same machine or over a network. DRb uses remote method invocation (RMI) to pass commands and data between processes.
  • Elixir is process-oriented and natively supports distribution and RPCs via message passing between nodes and local processes alike.
  • Elixir builds on top of the Erlang. It allows process communication (Elixir/Erlang processes, not OS processes) of the same network out of the box via Agents and message passing.
  • Google's Rust RPC framework Tarpc lets developers define the structure of messages using Rust's structs and traits, rather than using protobuf.[12]

Application-specific

[edit]
  • Action Message Format (AMF) allows Adobe Flex applications to communicate with back-ends or other applications that support AMF.
  • Remote Function Call is the standard SAP interface for communication between SAP systems. RFC calls a function to be executed in a remote system.

General

[edit]
  • NFS (Network File System) is one of the most prominent users of RPC
  • Open Network Computing RPC, by Sun Microsystems (also known as Sun RPC)
  • D-Bus open source IPC program provides similar function to CORBA.
  • SORCER provides the API and exertion-oriented language (EOL) for a federated method invocation
  • XML-RPC is an RPC protocol that uses XML to encode its calls and HTTP as a transport mechanism.
  • JSON-RPC is an RPC protocol that uses JSON-encoded messages.
  • JSON-WSP is an RPC protocol that is inspired from JSON-RPC.
  • SOAP is a successor of XML-RPC and also uses XML to encode its HTTP-based calls.
  • ZeroC's Internet Communications Engine (Ice) distributed computing platform.
  • Etch framework for building network services.
  • Apache Thrift protocol and framework.
  • CORBA provides remote procedure invocation through an intermediate layer called the object request broker.
  • Libevent provides a framework for creating RPC servers and clients.[13]
  • Windows Communication Foundation is an application programming interface in the .NET framework for building connected, service-oriented applications.
  • Microsoft .NET Remoting offers RPC facilities for distributed systems implemented on the Windows platform. It has been superseded by WCF.
  • The Microsoft DCOM uses MSRPC which is based on DCE/RPC
  • The Open Software Foundation DCE/RPC Distributed Computing Environment (also implemented by Microsoft).
  • Google Protocol Buffers (protobufs) package includes an interface definition language used for its RPC protocols[14] open sourced in 2015 as gRPC.[1]
  • WAMP combines RPC and Publish-Subscribe into a single, transport-agnostic protocol.
  • Google Web Toolkit uses an asynchronous RPC to communicate to the server service.[15]
  • Apache Avro provides RPC where client and server exchange schemas in the connection handshake and code generation is not required.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Remote procedure call

View on Grokipedia
from Grokipedia
A remote procedure call (RPC) is a protocol that enables a to execute a subroutine or procedure on a remote across a network, presenting the interaction to the programmer as if it were a local procedure call by abstracting away the details of network communication, parameter passing, and control transfer. The concept of RPC emerged in the late 1970s as a way to simplify distributed programming, with early discussions appearing in technical literature around 1976. The term "remote procedure call" was coined by Bruce J. Nelson in his 1981 PhD thesis at Carnegie-Mellon University. A foundational implementation was developed in 1983–1984 by Andrew D. Birrell and Bruce J. Nelson at PARC for the Cedar programming environment, which ran on computers connected via Ethernet; this system emphasized semantics matching local calls, use of stubs for interface generation, and optimizations for performance and security within a protected network. In 1988, formalized a widely adopted version through RFC 1057, defining the Open Network Computing (ONC) RPC protocol version 2, which specified message formats using (XDR), support for multiple transports like UDP and TCP, program versioning, and basic authentication mechanisms. RPC systems operate on core principles including client-side and server-side stubs that arguments into network messages and unmarshal results, ensuring no shared between caller and callee to maintain isolation. Unlike local procedure calls, which assume reliable, instantaneous execution in the same , RPCs must handle network-induced issues such as latency (often orders of magnitude slower), partial failures, and exceptions for communication errors, without access to the caller's globals or side effects. These mechanisms have made RPC a cornerstone of , facilitating client-server architectures in operating systems, file services, and .

Fundamentals

Definition and Overview

Remote procedure call (RPC) is a protocol that enables a program to execute a subroutine or procedure on a remote server as if it were a local call, by suspending the caller, transferring control and parameters across a network, executing the procedure remotely, and returning results transparently. This mechanism abstracts the underlying network complexities, such as packet transmission, retransmissions, and acknowledgments, allowing programmers to focus on application logic rather than low-level communication details. In distributed computing, RPC plays a central role by facilitating client-server interactions in networked environments, where distributed applications can leverage a familiar procedure call interface to build scalable systems without explicit handling of inter-machine communication. The core components include the client (the calling program), the server (the remote procedure executor), and stub routines: the client stub marshals arguments into network messages and invokes the , while the server stub unmarshals incoming messages and dispatches the call to the actual procedure. A high-level example illustrates RPC's transparency; a local procedure call might appear as result = add(a, b);, and the remote equivalent uses identical syntax, with the client stub handling the network transmission invisibly to the programmer. Unlike direct socket programming, which requires explicit management of byte streams, connections, and data serialization, RPC provides location transparency by mimicking local calls and hiding these details through stubs and runtime support.

Core Principles

Remote procedure calls (RPCs) are designed to provide a level of transparency that allows developers to invoke remote procedures as if they were local, abstracting away the complexities of . transparency hides the physical or of the server from the client, enabling procedure calls without specifying network details. Access transparency conceals the differences in representation and communication protocols between client and server, ensuring seamless across heterogeneous systems. Failure transparency masks errors such as network partitions or server crashes, presenting them in a manner similar to local exceptions, while performance transparency aims to mitigate the impact of network latency and variability, though it often requires additional mechanisms like caching or retries to approximate local call speeds. At the heart of RPC's abstraction layers are client and server stubs, which serve as intermediaries to handle the distribution details. The client stub packs procedure parameters into a network through a known as marshaling, transmitting them to the server, while the server stub unpacks these parameters via unmarshaling before invoking the actual procedure. Conversely, upon completion, the server stub marshals the results, and the client stub unmarshals them for return to the caller. This stub-based approach ensures that the programmer interacts only with familiar local procedure semantics, without direct involvement in communication. Traditional RPC implementations employ synchronous, blocking calls as the default model, where the client thread suspends execution until the server responds, mirroring the behavior of local procedure calls to maintain semantic consistency. This blocking nature simplifies programming but can introduce latency issues in high-latency networks. Non-blocking or asynchronous variants, where the client continues execution after issuing the call and later retrieves the result via callbacks or polling, address these limitations by improving concurrency and responsiveness, particularly in event-driven or multi-threaded applications. To ensure cross-platform compatibility, RPC systems handle data representation through standardized formats that convert machine-dependent data into a neutral, external form. (XDR), for instance, defines a canonical encoding for basic types like integers and strings, independent of host byte order or architecture, allowing parameters to be accurately interpreted on diverse systems during marshaling and unmarshaling. RPC provides semantic guarantees regarding execution to manage the uncertainties of distributed environments, typically adhering to at-most-once semantics where, if a response is received, the procedure has executed exactly once, but retries may result in no execution if failures occur. Achieving exactly-once semantics is challenging due to potential duplicate requests from network issues, often requiring idempotency in procedures or additional state management.

Historical Development

Origins in Early Computing

The development of remote procedure calls (RPC) emerged from the broader context of early in the 1970s, where systems and wide-area networks like highlighted the need for efficient resource sharing across disparate machines. systems, such as and the (CTSS), enabled multiple users to access centralized computing resources interactively, but as connected remote sites starting in 1969, researchers sought mechanisms to extend this sharing beyond local boundaries. The primary motivation was to overcome the limitations of and isolated mainframes by allowing programs on one computer to access data or services on another, fostering collaborative environments in academic and military research funded by . A pivotal early proposal for RPC as a subroutine-level originated in at PARC, where Jim White advanced concepts for remote invocation within the Distributed Programming System (DPS) integrated into SRI's NLS . This work built on discussions, including Jack Haverty's RFC 722, which outlined a request-response discipline for network servers, emphasizing synchronous communication to mimic local procedure calls. The motivations centered on simplifying distributed programming in an era of expanding networks, where low-level proved cumbersome; RPC drew inspiration from familiar procedure calls in sequential languages like Mesa (similar to Pascal) and , aiming to provide transparent semantics for parameters, exceptions, and across address spaces. Bruce Jay Nelson's 1981 dissertation further formalized these ideas, evaluating prototypes like Envoy and to demonstrate RPC's efficiency over Ethernet, achieving round-trip times as low as 149 microseconds on high-speed processors. Initial prototypes materialized in the Cedar/Mesa environment at PARC, where Birrell and Nelson implemented RPC in 1984 to support networked applications on Dorado workstations. This system generated stubs to handle marshaling and unmarshaling, ensuring at-most-once semantics and integrating with the Mesa language for seamless local-remote transitions, with simple calls completing in about 1 millisecond over Ethernet. The design prioritized ease of use for programmers, abstracting network details like binding and failure recovery. In the , RPC concepts gained formalization through Xerox's protocol, introduced in 1981 as part of the (XNS), which defined a standardized RPC layer for application protocols like remote filing and over PUP and Ethernet. emphasized type-safe data representation and idempotency, influencing subsequent systems. Concurrently, early UNIX implementations, such as rexec and rsh in 4.2BSD (1983), provided rudimentary RPC-like remote execution, using TCP for command invocation and output return, though lacking advanced features like stubs or encryption. These efforts solidified RPC as a foundational abstraction for distributed systems.

Key Milestones and Evolution

The 1980s marked the emergence of standardized RPC implementations that enabled practical distributed computing. Sun Microsystems introduced ONC RPC in 1984 as part of its Network File System (NFS) project, providing a lightweight protocol for remote invocations over UDP or TCP, which became one of the first widely adopted RPC systems in Unix environments. This binary protocol emphasized simplicity and performance, influencing subsequent standards. Building on these foundations, the Open Software Foundation (OSF) released DCE RPC in 1990 as a core component of its Distributed Computing Environment (DCE), offering enhanced features like secure authentication, directory services, and support for heterogeneous networks through an interface definition language (IDL). In the 1990s, RPC evolved toward object-oriented paradigms to support more complex distributed applications. The Object Management Group (OMG) integrated RPC mechanisms into the Common Object Request Broker Architecture (CORBA) with its 1.1 specification in 1991, enabling method invocations on distributed objects across languages and platforms. Similarly, Microsoft extended its Component Object Model (COM) with Distributed COM (DCOM) in 1996, adapting DCE RPC for Windows-based object invocations and facilitating enterprise integration in proprietary ecosystems. The 2000s saw RPC adapt to web-based architectures, shifting from proprietary binary protocols to XML and HTTP for broader interoperability. , proposed by in 1998, introduced a simple XML-over-HTTP format for remote calls, paving the way for web services. This culminated in , standardized by the W3C in 2000 as a protocol for exchanging structured information in web services, supporting RPC-style operations while incorporating and other extensions for enterprise use. Recent developments through 2025 have focused on high-performance, cloud-native RPC suited for . Google open-sourced in 2015, leveraging for multiplexing and for efficient serialization, which has become a staple for low-latency inter-service communication in scalable systems. In the 2020s, cloud providers enhanced RPC support; for instance, added native integration to API Gateway in 2021, enabling serverless RPC deployments with automatic scaling. Overall, RPC has transitioned from binary, platform-specific protocols to HTTP-centric and RESTful alternatives, yet retains prominence in architectures where offers superior efficiency over for internal service meshes.

Operational Mechanics

Message Passing Fundamentals

In remote procedure calls (RPC), communication between client and server relies on an exchange of structured messages that abstract the underlying network transport. The fundamental message types are the request (or call) message and the reply message. A request message contains the procedure identifier—typically a numeric value specifying the remote program, version, and specific procedure—along with the parameters to be passed to that procedure. These parameters are encoded in a platform-independent format to ensure across heterogeneous systems. The reply message, in turn, carries the procedure's results or an indication of , including any output values generated by the execution. This bidirectional message model mimics local procedure invocation while handling the distributed nature of the interaction. Central to message passing in RPC is the marshaling process, which serializes parameters and results into a byte stream suitable for transmission over the network. Marshaling involves converting machine-specific data representations into a canonical (XDR), a standard defined for ONC RPC that supports both primitive types like integers and strings, as well as complex types such as arrays, structures, and unions. For instance, an array of structures would be encoded by first serializing the array's length, followed by each element's fields in a defined order, ensuring no padding or issues arise during deserialization on the receiving end. This process, performed by client stubs before sending and by server stubs upon receipt, enables transparent handling of data without assumptions. The original RPC emphasized efficient marshaling to minimize overhead, fitting typical messages into single packets where possible. RPC messages are typically transported over reliable protocols like TCP for connection-oriented delivery or UDP for lightweight, datagram-based exchanges, with the choice influencing reliability semantics. Over TCP, messages are framed with length prefixes to delineate records in the byte stream, providing inherent ordering and delivery guarantees. UDP, being connectionless, requires explicit client-side retransmission logic for lost packets, often using timeouts to trigger retries. handling is embedded in the message protocol through status codes in replies; for example, accept errors include codes for program unavailability (1), procedure unavailability (3), invalid arguments (4, e.g., garbage parameters), and system errors (5), while reject errors cover RPC version mismatches (0) or authentication failures (1). Timeouts are managed at the application or , with replies indicating failures like invalid parameters via these codes to inform the client without further negotiation. To support robust operation in unreliable networks, RPC incorporates idempotency considerations, primarily through at-most-once invocation semantics enabled by a (xid) in each message. Clients include the xid in requests and retransmit with the same value if no timely reply is received, allowing servers to detect duplicates via a cache of recent xids and avoid re-executing non-idempotent procedures that could cause side effects, such as duplicate database updates. While exactly-once semantics are not guaranteed due to potential server crashes or network partitions, this mechanism ensures retries do not amplify errors, with the original RPC design prioritizing exactly-once under normal conditions when a reply is returned.

Sequence of Events in RPC

The sequence of events in a remote procedure call (RPC) begins when a invokes a remote procedure, abstracting the distributed nature of the interaction to resemble a local subroutine call. This relies on client and server stubs—automatically generated that handles the low-level details of communication—to maintain transparency for the . The triggers a series of steps involving argument preparation, network transmission, execution on the server, and result return, all orchestrated by the RPC . First, the client process makes a local call to the client stub, passing the procedure name and arguments as if calling a local function. The client stub then marshals these arguments—converting them into a network-transmittable format, such as byte streams or packets—along with the procedure specification, ensuring compatibility across machines. This marshaled request is packaged into one or more packets and handed to the RPC runtime for transmission over the network to the server's address, which is assumed to be resolved prior to invocation. The client process typically blocks at this point, suspending execution until the response arrives, mimicking synchronous local calls. Upon receipt, the server's RPC runtime delivers the packets to the server stub. The server stub unmarshals the arguments, reconstructing them into the appropriate format for the server's , and then dispatches a local call to the actual server procedure with these parameters. The server procedure executes as a standard local function, performing the requested computation without awareness of its remote origin. Once execution completes, the procedure returns its results (including any output parameters or exceptions) to the server stub. The server stub then marshals the results into a reply packet and passes it to the RPC runtime for transmission back across to the client. On the client side, the RPC runtime receives the reply, and the client stub unmarshals the results, converting them back into the client's format before returning the value to the invoking process. This resumes the client's execution, delivering the outcome as if from a local procedure. The entire round-trip aims for at-most-once semantics, where the call executes no more than once despite potential network issues. RPC systems must handle exceptions arising from network unreliability, such as lost packets, timeouts, or server failures, integrated into the to preserve reliability. If packets are lost during transmission, the RPC runtime detects this via acknowledgments or numbers and initiates retransmissions of the request or reply, ensuring idempotency to avoid duplicate executions. Timeouts occur if no response arrives within a predefined interval, prompting the client stub to raise an exception (e.g., a communication ) to the client , similar to how local calls might handle deadlocks. Probe packets may be sent periodically to detect server crashes or network partitions, notifying the client via exceptions without altering the core . These mechanisms do not guarantee exactly-once execution but provide robust detection and recovery.

Binding and Contact Mechanisms

In remote procedure calls (RPC), binding refers to the process of establishing a logical connection between a client and a server, enabling the client to locate and invoke procedures on the remote server. This mechanism resolves the client's reference to the server's interface, typically involving the specification of network addresses, ports, and identifiers for the target procedure. Binding is essential prior to invocation, as it handles the variability in server locations and configurations across distributed systems. Static binding occurs at compile-time or link-time, where the client's code is resolved to fixed server addresses or ports hardcoded into the application. This approach simplifies development by embedding server details directly, avoiding runtime discovery overhead, but it limits flexibility since changes to server locations require recompilation. In early RPC designs, static binding was favored for environments with stable, known server endpoints. Dynamic binding, in contrast, resolves server details at runtime, allowing clients to discover available servers without prior knowledge of their exact locations. This is achieved through intermediary services that map abstract identifiers to concrete network endpoints. For instance, in the Open Network Computing (ONC) RPC protocol, the rpcbind service (formerly portmapper) operates on well-known TCP/UDP port 111, where servers register their program numbers and versions upon startup, and clients query this port to obtain the corresponding dynamic port assignments for the desired service. This enables transport-independent binding using universal addresses in ASCII string format. Naming services provide a higher-level for dynamic binding, associating human-readable or hierarchical names with server objects or interfaces. In the (CORBA), the Naming Service maintains a of bindings within naming contexts, where clients use operations like bind to register object references and resolve to retrieve them by name, supporting nested hierarchies for scalable resolution. Similarly, in the (DCE) RPC, universal unique identifiers (UUIDs) uniquely identify interfaces and optional object endpoints; servers register these with an endpoint mapper, which clients query to complete partial bindings lacking endpoint details. Universal Resource Locators (URLs) and Domain Name System (DNS) resolution extend naming services to RPC endpoints by mapping symbolic names to IP addresses and ports, facilitating location transparency in internet-scale deployments. For example, DNS-based service discovery allows clients to resolve RPC server hostnames to addresses dynamically, often combined with port mappers for full endpoint binding. To support scalability and reliability, binding mechanisms incorporate load balancing and failover through multiple server replicas. In DCE RPC, servers can register vectors of endpoints with the mapper, enabling clients to select from available replicas for distributing load or redirecting to healthy instances upon failure. ONC RPC similarly allows multiple registrations under the same program number, permitting clients to query and bind to alternate ports for balanced invocation across replicas. These techniques ensure continued availability without single points of failure in the binding phase.

Implementations and Analogues

Language-Specific Variants

Remote procedure call (RPC) implementations vary across programming languages, often integrating with native syntax, libraries, and tools to facilitate seamless remote invocations while addressing language-specific concerns like type marshalling and stub generation. These variants typically leverage interface definition languages (IDLs) or built-in mechanisms to handle data , ensuring compatibility within the language ecosystem and, where possible, across languages through standardized encodings. In C and C++, ONC RPC, originally developed by Sun Microsystems, provides a foundational implementation using the rpcgen tool to automate stub generation from interface definitions written in XDR (eXternal Data Representation), a language-agnostic IDL that standardizes type handling for cross-language compatibility by specifying encodings like big-endian integers and padded structures. The rpcgen compiler processes .x files to produce client stubs, server stubs, header files, and XDR routines, enabling developers to write RPC programs as if they were local functions; for example, a simple procedure definition in XDR can generate C code for remote calls over UDP or TCP. This approach emphasizes static compilation for performance, with XDR ensuring portable data representation across heterogeneous systems. Java's Remote Method Invocation (RMI), introduced in JDK 1.1 in 1997, supports RPC through interface-based remote objects, where developers define remote interfaces extending java.rmi.Remote to specify callable methods, and implement them in classes that extend java.rmi.server.UnicastRemoteObject for automatic stub export. The RMI registry, accessed via java.rmi.registry.Registry and LocateRegistry, serves as a naming service for binding and looking up remote objects by name, typically on port 1099, allowing clients to obtain stubs dynamically for method invocation. Java RMI handles type marshalling via object serialization, passing remote references for objects implementing Remote while serializing primitives and non-remote objects by value. Python offers RPC support through standard libraries like xmlrpc.client, which provides a dynamic proxy for invoking methods on XML-RPC servers over HTTP, where ServerProxy creates an object that maps method calls to XML-encoded requests without requiring predefined stubs. For more advanced object-oriented RPC, the third-party Pyro5 library enables dynamic proxies that allow transparent remote access to Python objects, supporting features like method invocation, attribute access, and even callbacks with minimal boilerplate, using serialization for type handling. Pyro5 proxies can be created from URIs or object IDs, facilitating ad-hoc remote calls while handling exceptions and one-way invocations. Go's net/rpc package, part of the , implements RPC using exported methods on server objects, where clients dial connections to call procedures synchronously or asynchronously, defaulting to gob encoding for type-safe marshalling. For broader compatibility, the net/rpc/jsonrpc subpackage supports 1.0 over HTTP, allowing clients to send -formatted requests via DialHTTP and integrating with Go's http package for server setup using HandleHTTP. This enables cross-language use where handles diverse types like structs and slices, though Go-specific conventions require methods to follow a receiver-arguments-error signature. Differences in type handling across these variants often stem from language-specific IDLs or serialization strategies; for instance, ONC RPC's XDR provides explicit, cross-language type mappings for fixed and variable arrays, while Java RMI relies on JVM serialization for object graphs, and Python's xmlrpc uses XML schemas for basic types, potentially limiting complex structures without extensions like Pyro5's pickle-based serialization. These approaches balance ease of use within the language against , with IDLs like XDR promoting for multi-language environments.

Application and Framework-Specific Uses

In database systems, remote procedure calls facilitate distributed querying and execution across interconnected instances. PostgreSQL's dblink extension enables connections to remote databases, allowing the execution of SQL statements, including calls to stored procedures, as if they were local. For instance, dblink_exec can invoke a remote procedure by passing the procedure call as a SQL command string, supporting and modification across servers. Similarly, uses database links to access objects on remote databases, where procedures are invoked by appending the link name to the procedure identifier, such as procedure_name@dblink, enabling seamless execution of remote logic within local transactions. In web services and architectures, RPC frameworks like Thrift and integrate deeply to handle inter-service communication. Thrift, originally developed by in 2007, provides a scalable, cross-language RPC system for defining and invoking services, emphasizing efficient and transport for high-throughput applications such as backends. , built on , is commonly deployed in service meshes like Istio, where it supports proxyless integration for direct service discovery, traffic routing, and load balancing among , reducing latency in containerized environments. For operating systems, Windows employs the Microsoft Remote Procedure Call (MSRPC) protocol to enable distributed system calls across networked machines. MSRPC extends the standard, allowing client applications to invoke server procedures transparently, as seen in components like for authentication and management tasks. In cloud applications, RPC patterns underpin serverless and container orchestration workflows. functions can be invoked synchronously via protocols, often through API Gateway integrations that translate requests into Lambda execution events, supporting high-performance, event-driven architectures for scalable processing. In , service calls frequently leverage for efficient pod-to-pod communication, with built-in load balancing ensuring even distribution of RPC traffic across replicas to maintain reliability in distributed deployments. A notable case study is Hadoop's use of RPC for high-performance distributed data processing. Hadoop's framework employs a custom RPC layer, based on abstractions like the IPC (Inter-Process Communication) protocol, to coordinate tasks between the NameNode, DataNodes, and client applications, enabling fault-tolerant execution of MapReduce jobs across clusters handling petabyte-scale datasets. This RPC mechanism ensures low-latency communication for metadata operations and data transfers, contributing to Hadoop's scalability in big data environments.

General Architectural Analogues

Remote Procedure Call (RPC) shares architectural similarities with several distributed communication paradigms but differs in its emphasis on synchronous, procedural invocation that mimics local function calls across network boundaries. One key analogue is the Object Request Broker (ORB) model, exemplified by the (CORBA), which extends RPC principles to support . In CORBA, clients invoke operations on remote objects via object references—unique identifiers that encapsulate location and interface details—allowing transparent access similar to RPC stubs but with added support for , polymorphism, and dynamic invocation through an Interface Definition Language (IDL). Unlike basic RPC, which focuses on stateless procedure calls, CORBA's ORB mediates requests across heterogeneous environments, enabling interoperability among diverse implementations while maintaining request-response semantics. In contrast to RPC's synchronous, tightly coupled nature, (MOM) such as the Java Message Service (JMS) employs an asynchronous, messaging paradigm. RPC requires the caller to block until a response returns, enforcing a direct procedural flow, whereas MOM facilitates one-way through queues or topics, where producers and consumers operate independently without knowledge of each other. For instance, JMS implementations like prioritize bandwidth-efficient pipelining over latency-sensitive responses, making them suitable for loosely coupled systems but diverging from RPC's immediate invocation model. This architectural shift in MOM reduces temporal , as messages persist until processed, unlike RPC's ephemeral request-response exchanges. RPC also contrasts with resource-oriented architectures like Representational State Transfer () over HTTP APIs, where communication revolves around manipulating resources via uniform interfaces rather than executing procedures. In RPC, operations are action-centric, with clients specifying methods and parameters akin to local APIs, often using custom protocols for efficiency. , however, treats services as collections of addressable resources (e.g., URIs representing entities), employing standard HTTP methods (GET, POST, PUT, DELETE) to perform CRUD operations, which promotes and hypermedia-driven discoverability but can introduce overhead for complex, multi-step procedures compared to RPC's streamlined calls. This resource-focused design in enhances in web-scale environments, while RPC prioritizes performance in procedure-heavy scenarios. Event-driven systems, particularly publish-subscribe (pub-sub) models like those in , further diverge from RPC by emphasizing one-to-many, asynchronous event dissemination over point-to-point invocation. In pub-sub architectures, publishers broadcast events to topics without targeting specific recipients, and subscribers receive notifications based on interests, fostering and real-time reactivity. RPC's synchronous —where sender and receiver synchronize on message boundaries and content—contrasts sharply with pub-sub's push-based, flow, which avoids blocking and supports high-throughput event streams but lacks RPC's direct return values. Kafka's log-based pub-sub, for example, ensures durable event storage and ordered delivery, enabling scalable processing absent in RPC's transient interactions. Hybrid approaches like represent evolutions that blend RPC's procedural efficiency with modern web standards, specifically for transport. maps RPC semantics—defined via for structured, binary —onto 's multiplexing and bidirectional streaming, allowing multiple concurrent calls over a single connection without the head-of-line blocking common in HTTP/1.1-based RPC variants. This integration preserves RPC's method-invocation transparency while leveraging 's header compression and flow control for web-compatible, high-performance distributed services, bridging traditional RPC with REST-like interoperability in cloud-native ecosystems.

Advantages and Limitations

Benefits of RPC

Remote Procedure Call (RPC) offers significant developer transparency by allowing programmers to execute remote operations using syntax identical to local function calls, thereby concealing the underlying network intricacies such as message , transmission, and error handling. This simplifies the development of distributed applications, making it as straightforward as conventional and reducing the amount of required for . As noted in the seminal work on RPC implementation, this approach makes distributed computation "easy" by leveraging automatically generated stubs that handle the marshalling and unmarshalling of parameters. RPC enhances in distributed systems by enabling clear separation of client and server components through well-defined interfaces, which supports independent development, testing, and scaling of modules. Stub generators facilitate separate compilation of client and server , promoting reusable and maintainable architectures without tight between distributed entities. This is particularly beneficial in large-scale systems where components can evolve independently while maintaining consistent interaction patterns. In terms of performance, RPC is well-suited for fine-grained, synchronous calls, achieving efficiencies close to raw network transmission times—often within a factor of five—by omitting unnecessary protocol layers and optimizing data transfer for procedure-like invocations. RPC supports interoperability across heterogeneous environments via Interface Definition Languages (IDLs), which define procedure signatures in a language-agnostic manner, allowing code generated in one programming language to seamlessly invoke services implemented in another. This capability aids integration in polyglot systems, such as those combining C++, Java, and Python components. In latency-sensitive real-time applications, RPC's low-latency and reliable invocation model enables efficient, high-throughput data exchange.

Challenges and Drawbacks

Remote procedure calls (RPCs) introduce several inherent challenges in distributed systems, primarily stemming from the discrepancies between local and remote execution environments. Unlike local procedure calls, which occur within a single with negligible overhead, RPCs must contend with network unpredictability, leading to performance degradation and reliability issues. These drawbacks often necessitate additional mechanisms for mitigation, though they can complicate system design and maintenance. Network latency represents a fundamental limitation of RPCs, as the synchronous nature of most implementations requires clients to block until a response is received, amplifying the impact of round-trip times across potentially unreliable networks. This overhead can be orders of magnitude higher than local calls; for instance, early RPC systems reported remote invocations taking up to 20 times longer than local ones due to parameter marshaling, transmission delays, and unmarshaling. Message losses, reordering, and variable delays further exacerbate this, often requiring acknowledgments and timeouts that add to the effective latency. Partial failure handling poses significant challenges in RPC systems, where detecting and recovering from remote crashes or network partitions is nontrivial. Server failures can result in lost state, such as open file handles, leaving clients in inconsistent states without clear mechanisms for . Moreover, client crashes may create "orphans"—ongoing server computations that consume resources without completion—violating desired semantics like at-most-once . Distinguishing between slow servers and outright failures often relies on heuristics like periodic pings, but these can lead to false positives or prolonged hangs, complicating recovery in heterogeneous environments. Scalability limits arise from the tight between client and server interfaces in RPC designs, which hinder horizontal scaling in large distributed systems. Traditional RPCs support only point-to-point communication, lacking native or broadcast capabilities despite underlying network hardware support, thus restricting efficient to multiple recipients. Server-side for active calls can also bottleneck performance, with early implementations capping call rates at less than one per second per machine to avoid overload. Modern variants like incorporate load balancers and to improve for high-throughput scenarios. Versioning problems in RPC interfaces stem from the evolution of procedures and data types, often requiring coordinated updates across clients and servers to avoid breaking changes. In heterogeneous systems, varying parameter types and counts—particularly in languages like C—complicate marshaling, while persistent data formats demand translation for backward compatibility. Implementations like SunRPC use version numbers in identifiers to manage this, but mismatches can lead to runtime failures or require complex proxy layers, increasing deployment overhead. Debugging RPC-based applications is particularly arduous due to the of network boundaries, which obscures the flow of control and data across distributed components. Tracing issues requires specialized tools to monitor stubs, bindings, and message exchanges, as global variables, pointers, and exceptions behave differently remotely, often resulting in opaque errors like unexpected messages or incomplete traces. The physical separation of machines further demands remote interfaces, such as decentralized or abstract layers, to and inspect executions without disrupting unrelated processes, yet these add significant complexity.

Security and Modern Considerations

Security Vulnerabilities

Remote procedure call (RPC) systems, particularly early implementations like ONC RPC, suffer from significant authentication weaknesses that expose them to spoofing attacks. The original ONC RPC protocol provided limited authentication flavors, such as AUTH_NONE, which offers no identity verification and allows any caller to impersonate legitimate users without detection. AUTH_SYS, the default for many systems, relies on easily forged UNIX-style credentials transmitted in plaintext, enabling attackers to spoof user identities and gain unauthorized access to procedures. Additionally, AUTH_DH employs a flawed Diffie-Hellman key exchange with a small prime modulus, making it susceptible to cryptographic attacks that compromise shared secrets and facilitate impersonation. These deficiencies stem from the protocol's design priorities on simplicity over security, as outlined in its foundational specification. Authorization and access control in RPC introduce further risks, where insufficient verification of caller privileges can result in . In RPC frameworks, procedures often execute with varying levels of system privileges, but without robust checks, an authenticated but low-privilege caller can invoke high-privilege operations, such as or configuration changes. For instance, in large-scale RPC services, misconfigured s have allowed escalation from user-level to administrative privileges by exploiting unverified procedure invocations. Automated analysis tools have identified such vulnerabilities in production RPC systems, highlighting how incomplete logic amplifies the impact of initial breaches. Network exposure compounds these issues, as RPC communications typically occur over unencrypted TCP or UDP channels, rendering them vulnerable to and man-in-the-middle (MITM) attacks. In ONC RPC, message payloads—including sensitive parameters and responses—are sent in , allowing attackers to intercept and inspect data in transit or alter it undetected to inject malicious content. This lack of integrity and is inherent to the protocol's , which defers to higher layers but often leaves it unimplemented in practice. Denial-of-service (DoS) attacks exploit RPC's resource-intensive nature, leading to amplification effects or exhaustion through crafted calls. Recursive or deeply nested procedure invocations can trigger unbounded computation or memory allocation on the server, consuming CPU and RAM until services become unresponsive; without recursion limits, a single malicious call can amplify into widespread disruption. Resource exhaustion also arises from flooding endpoints with high-volume requests, overwhelming port mappers or endpoint handlers in protocols like ONC RPC, where stateless UDP support exacerbates the issue by enabling spoofed packets without connection overhead. Historical exploits underscore these vulnerabilities, notably in Microsoft RPC (MSRPC) during the early 2000s. The MS03-026 in the DCOM interface allowed remote unauthenticated attackers to execute arbitrary code by sending malformed RPC requests to ports like 135 or 445, leading to full system compromise and widespread worm propagation, such as the Blaster worm that infected hundreds of thousands of machines in 2003. Similar s in MSRPC components, like the Server service, enabled code execution or crashes, demonstrating how implementation flaws in authentication and parsing amplified network-based risks.

Best Practices and Contemporary Adaptations

To ensure in RPC systems, via TLS/SSL is a fundamental practice, particularly in protocols like , which supports and recommends TLS for production connections to protect data in transit from interception or tampering. Authentication mechanisms such as and JWT tokens further enhance security by verifying client identities before granting access to RPC endpoints, allowing fine-grained in distributed environments. For resilience against network failures, implementing idempotency in RPC operations is essential; this involves assigning unique identifiers to requests, ensuring that retries produce the same outcome without unintended side effects, such as duplicate processing in payment systems. Retry strategies complement this by exponentially backing off after failures, while circuit breakers prevent cascading issues by halting calls to unresponsive services until recovery is detected, thereby maintaining overall system stability. In cloud-based deployments, API gateways serve as proxies for RPC traffic, enabling centralized monitoring of call volumes, latency, and error rates, while enforcing to mitigate abuse and ensure resource fairness across services. Contemporary adaptations of RPC as of 2025 emphasize serverless architectures integrated with , where functions execute RPC calls closer to users for reduced latency in real-time applications like IoT , supported by platforms that abstract infrastructure management. Additionally, enables browser-based RPC invocations through protocols like gRPC-Web, allowing client-side code to directly call server procedures without plugins, enhancing performance in web applications via compiled modules that interface seamlessly with transports. In 2025, ongoing security challenges in RPC were highlighted by vulnerabilities in Windows RPC implementations, including the Win-DoS epidemic (disclosed August 2025), which exploited RPC for DoS and DDoS attacks via public domain controllers, and authentication coercion techniques targeting obscure RPC interfaces (November 2025). Microsoft responded with patches like KB5066014 for CVE-2025-49716, hardening Netlogon RPC against unauthenticated calls and tightening access controls to prevent spoofing and . These incidents underscore the continued need for protocol updates, such as enhanced and in modern RPC variants. Best practices for long-term maintainability include interface versioning, where new RPC methods are added without breaking existing contracts—often by appending version suffixes to service definitions—facilitating gradual client upgrades in ecosystems. For , tools like are widely used to collect RPC-specific metrics, such as request counts and durations, exposing them via standardized endpoints for alerting and visualization in systems like .

References

  1. http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-83-7_Implementing_Remote_Procedure_Calls.pdf
  2. https://cs.nyu.edu/~apanda/classes/fa22/papers/nelson81remote.pdf
  3. https://datatracker.ietf.org/doc/html/rfc1057
  4. https://courses.cs.washington.edu/courses/csep552/18wi/papers/birrell-rpc.pdf
  5. https://cs.brown.edu/courses/csci0300/2022/notes/l24.html
  6. https://www.cs.cmu.edu/~srini/15-440/2015.Fall/lectures/01-intro.pdf
  7. https://www.cs.cmu.edu/~15712/papers/birrell84.pdf
  8. https://grpc.io/docs/what-is-grpc/core-concepts/
  9. https://datatracker.ietf.org/doc/html/rfc1014
  10. https://apps.dtic.mil/sti/tr/pdf/ADA115440.pdf
  11. https://www.cs.cornell.edu/courses/cs6410/2009fa/lectures/11-rpc.ppt
  12. https://www.dre.vanderbilt.edu/~schmidt/PDF/docwc.pdf
  13. http://davenet.userland.com/1998/02/27/rpcOverHttpViaXml
  14. https://www.w3.org/TR/2000/NOTE-SOAP-20000508/
  15. https://developers.googleblog.com/introducing-grpc-a-new-open-source-http2-rpc-framework/
  16. https://www.cs.uic.edu/~ckanich/cs484/f24/readings/chapter-3-server-side-web-development/non-rest-apis/index.html
  17. https://datatracker.ietf.org/doc/html/rfc5531
  18. https://datatracker.ietf.org/doc/html/rfc4506
  19. https://dl.acm.org/doi/10.1145/2080.357392
  20. https://www.cl.cam.ac.uk/~jac22/books/ods/ods/node60.html
  21. https://www.rfc-editor.org/rfc/rfc1833.html
  22. https://www.omg.org/spec/NAM/1.1/PDF
  23. https://pubs.opengroup.org/onlinepubs/9629399/chap2.htm
  24. https://pubs.opengroup.org/onlinepubs/9629399/chap4.htm
  25. https://docs.oracle.com/cd/E18752_01/html/816-1435/rpcgenpguide-24243.html
  26. https://www.omscs-notes.com/operating-systems/remote-procedure-calls/
  27. https://sunsite.icm.edu.pl/pub/programming/java/javasoft-docs/jdk1.1/rmi.pdf
  28. https://docs.oracle.com/javase/tutorial/rmi/implementing.html
  29. https://docs.python.org/3/library/xmlrpc.client.html
  30. https://packages.debian.org/sid/python3-pyro5
  31. https://pkg.go.dev/net/rpc
  32. https://www.postgresql.org/docs/current/contrib-dblink-exec.html
  33. https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/CREATE-DATABASE-LINK.html
  34. https://thrift.apache.org/static/files/thrift-20070401.pdf
  35. https://istio.io/latest/blog/2021/proxyless-grpc/
  36. https://learn.microsoft.com/en-us/windows/win32/rpc/rpc-start-page
  37. https://aws.amazon.com/blogs/opensource/the-versatility-of-grpc-an-open-source-high-performance-rpc-framework/
  38. https://kubernetes.io/blog/2018/11/07/grpc-load-balancing-on-kubernetes-without-tears/
  39. https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html
  40. https://www.omg.org/spec/CORBA/1.2/PDF
  41. https://activemq.apache.org/components/artemis/documentation/latest/messaging-concepts.html
  42. https://docs.oracle.com/cd/E19465-01/819-2574/intro.html
  43. https://nordicapis.com/whats-the-difference-between-rpc-and-rest/
  44. https://www.altexsoft.com/blog/soap-vs-rest-vs-graphql-vs-rpc/
  45. https://www.altexsoft.com/blog/event-driven-architecture-pub-sub/
  46. https://www.cs.princeton.edu/courses/archive/spr17/cos598D/PublishSubscribe03.pdf
  47. https://grpc.io/docs/what-is-grpc/introduction/
  48. https://www.cs.cmu.edu/afs/cs/academic/class/15712-f15/www/lectures/03-rpc.pdf
  49. https://www.techtarget.com/searchapparchitecture/definition/Remote-Procedure-Call-RPC
  50. https://cloud.google.com/blog/products/api-management/bridge-the-gap-between-grpc-and-rest-http-apis
  51. https://book.systemsapproach.org/e2e/rpc.html
  52. https://journals.pen2print.org/index.php/ijr/article/download/909/858
  53. https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/overview-of-rpc-debugging
  54. https://datatracker.ietf.org/doc/html/rfc2695
  55. https://dl.acm.org/doi/10.1145/3433210.3453076
  56. https://learn.microsoft.com/en-us/security-updates/securitybulletins/2003/ms03-026
  57. https://www.itsecurityguru.org/2024/12/13/what-is-grpc-and-how-does-it-enhance-api-security/
  58. https://konghq.com/blog/learning-center/what-is-grpc
  59. https://grpc.io/docs/guides/auth/
  60. https://sultanov.dev/blog/securing-java-grpc-services-with-jwt-based-authentication/
  61. https://reflectoring.io/retry-with-resilience4j/
  62. https://dev.to/rafaeljcamara/downstream-resiliency-the-timeout-retry-and-circuit-breaker-patterns-2bej
  63. https://www.linkedin.com/posts/surajrajeshgupta_backendengineering-systemdesign-softwarearchitecture-activity-7370759108200751104-PtN0
  64. https://api7.ai/learning-center/api-gateway-guide/api-gateway-grpc-support
  65. https://www.paloaltonetworks.com/cyberpedia/what-is-api-gateway
  66. https://tyk.io/blog/microservices-api-gateway/
  67. https://www.researchgate.net/publication/389283051_Serverless_Edge_Computing_A_Taxonomy_Systematic_Literature_Review_Current_Trends_and_Research_Challenges
  68. https://rentamac.io/serverless-computing-trends/
  69. https://medium.com/wasm/the-future-of-distributed-computing-transitioning-microservices-to-webassembly-wasm-via-rpc-ad6f07cbb497
  70. https://developers.cloudflare.com/workers/runtime-apis/rpc/
  71. https://blog.stevensanderson.com/2020/01/15/2020-01-15-grpc-web-in-blazor-webassembly/
  72. https://www.safebreach.com/blog/win-dos-epidemic-abusing-rpc-for-dos-and-ddos/
  73. https://unit42.paloaltonetworks.com/authentication-coercion/
  74. https://support.microsoft.com/en-us/topic/kb5066014-netlogon-rpc-hardening-cve-2025-49716-38a0bc06-507c-47d4-be0f-ca1acab02c68
  75. https://www.itwinjs.org/learning/rpcinterface/
  76. https://api7.ai/learning-center/api-101/api-versioning
  77. https://github.com/grpc-ecosystem/go-grpc-prometheus
  78. https://dubbo.apache.org/en/overview/mannual/golang-sdk/tutorial/observability/rpc_metrics/
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.