Удалённый вызов процедур: механизмы и реализация

Mechanism to allow software to execute a remote procedure
In distributed computing, a Remote Procedure Call (RPC) is when a computer program causes a procedure (subroutine) to execute in a different address space (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 client–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 different. Many different (often incompatible) technologies have been used to implement the concept.

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. Remote procedure calls used in modern operating systems trace their roots back to the RC 4000 multiprogramming system, which used a request response communication protocol for process synchronization. The idea of treating network operations as remote procedure calls goes back at least to the 1970s in early ARPANET documents. In 1978, Per Brinch Hansen proposed Distributed Processes, a language for distributed computing based on "external requests" consisting of procedure calls between processes. One of the earliest practical implementations was in 1982 by Brian Randell and colleagues for their Newcastle Connection between UNIX machines. This was soon followed by "Lupine" by Andrew Birrell and Bruce Nelson in the Cedar environment at Xerox PARC. Lupine automatically generated stubs, providing type safe bindings, and used an efficient protocol for communication. 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. Erlang 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 VM and 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.

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.