Mechanism to allow software to execute a remote procedure
Indistributed computing, aremote procedure call (RPC) is when a computer program causes aprocedure (subroutine) to execute in a differentaddress space of the current process (commonly on another computer on a sharedcomputer network), which is written as if it were a normal (local) procedure call, without theprogrammer 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 isclient, executor isserver), typically implemented via arequest–response message passing system. In theobject-oriented programming paradigm, RPCs are represented byremote method invocation (RMI). The RPC model implies a level oflocation 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.
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 earlyARPANET 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 byBrian Randell and colleagues for theirNewcastle Connection between UNIX machines.[7] This was soon followed by "Lupine" by Andrew Birrell and Bruce Nelson in theCedar environment atXerox 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 byXerox 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 ofobject-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.
RPC is a request–response protocol. An RPC is initiated by theclient, which sends a request message to a known remoteserver 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 anXMLHttpRequest. 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 writtenlow-level subsystems.
To let different clients access servers, a number of standardized RPC systems have been created. Most of these use aninterface 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.
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 inPython, 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.
Erlang is process-oriented and natively supports distribution and RPCs via message passing between nodes and local processes alike.
Elixir builds on top of theErlang. 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 frameworkTarpc lets developers define the structure of messages using Rust's structs and traits, rather than using protobuf.[12]
