Remote procedure call

from Wikipedia, the free encyclopedia

Remote Procedure Call ( RPC ; engl. "Call to a remote procedure") is a technique for the realization of inter-process communication . It enables functions to be called in other address spaces . Normally, the called functions are executed on a different computer than the calling program. There are many implementations of this technique that are usually incompatible with one another.

History and dissemination

The basic idea of ​​RPC was first published in 1976 by James E. White in RFC 707 . One of the first implementations is Xerox Courier , which is part of the Xerox Network System (XNS) and is also used in Novell's Netware . The developers Andrew Birrell and Bruce Nelson received the ACM Software System Award for this in 1994 . The exact structure of RPC is described in RFC 1057 and RFC 5531 .

The most widespread variant is the ONC RPC ( Open Network Computing Remote Procedure Call) , which is often referred to as Sun RPC. ONC RPC was originally developed by Sun Microsystems for the Network File System (NFS) . For this RPC variant there is also an implementation in Linux .

The Distributed Computing Environment Remote Procedure Call (DCE RPC) implementation is also widely used. Microsoft derived Microsoft RPC (MSRPC) from the DCE RPC 1.1 reference implementation. DCOM was later implemented on this basis . The experiences from DCOM flowed into .NET Remoting .

procedure

RPC is one way to implement a client-server model . Communication begins with the client sending a request to a known server and waiting for the response. In the request, the client specifies which function is to be carried out with which parameters. The server processes the request and sends the response back to the client. After receiving the message, the client can continue processing.

When using RPC, different error constellations can occur due to communication errors, which must be observed and processed.

Error semantics

RPC is generally based on UDP . Hence it is a connectionless communication. This has the advantage that there is no traffic overhead from ACK packets. However, the UDP packet size is not sufficient for large responses. Therefore, two types of RPC protocols must be assumed here: Request-Reply and Request-Reply-ACK. This must be taken into account because each of these two protocols has different sources of error and therefore different error handling is necessary. In the event of an error, depending on the implementation, no results, exactly one result or many results can be received. For this purpose, the following "error semantics" can be selected on the client side: maybe , at-least-once , exactly-once and at-most-once .

If errors occur, the following can happen depending on the specified error semantics:

(If no errors occur, all semantics guarantee that the procedure will be executed once.)

Type In the event of an error, a request is ... Filtering of received duplicates
maybe ... not sent again. no treatment
at-least-once ... sent again. No The removed procedure is executed repeatedly if a duplicate is received (only recommended for idempotent operations).
at-most-once ... sent again. Yes Duplicates are filtered, either complete execution of the job or error messages.
exactly-once ... sent again. Yes Duplicates are also filtered out. Furthermore, even if the system fails, the execution of the order is guaranteed beyond the restart. However, some books state that exactly-once is not possible with distributed systems.

In general, however, there is no guarantee whatsoever. Because if z. For example, if a network node fails permanently, not a single execution is possible in any case.

functionality

In order to call an external procedure, a message must be sent from the client process to the server process. This must contain the name of the procedure (or an ID) and the associated parameter values. The message should ultimately arrive at a server process that implements exactly this procedure (required for the server: register (notification, ensuring public access); for this required for the client: lookup and binding ).

The search for a corresponding server can be implemented by broadcast (in a local network) or by using a directory service . (The directory service holds a globally available object, more precisely a directory of servers and the procedures implemented by them.)

The search and the coding, but also z. B. necessary recovery measures ( error recoveries ) are carried out on the client side by the client stub .

The most important component on the server side is the port mapper - daemon that at ONC RPC on UDP - and TCP - Port listening 111; With DCE RPC, this function is taken over by the endpoint mapper , which listens on UDP and TCP port 135. Portmapper resp. Endpoint mappers take over the coordination of the function calls requested by the client. Every program that wants to provide RPC services on the server must therefore be known to it.

When the computer on which the server process is running receives the request, either the process that executes the procedure is created with the help of the portmap, or alternatively a process can only be activated (in this case a predefined number of held by processes). Or a new thread is created.

See also

Web links

Individual evidence

  1. ↑ James E. White:  RFC 707 . - A high-level framework for network-based resource sharing . January 14, 1976 ( Proceedings of the 1976 National Computer Conference  ).
  2. ↑ Andrew D. Birrell, Bruce Jay Nelson: Implementing Remote Procedure Calls . In: Xerox Palo Alto Research Center (Ed.): ACM Transactions on Computer Systems . tape 2 , no. 1 , 1984, p. 39-49 ( PDF ).
  3. ↑ Günther Bengel: Basic course on distributed systems . Vieweg and Teubner Verlag, 2005, ISBN 3-528-25738-5 .
  4. ↑ X. Feng, J. Shen, Y. Fan: REST: An alternative to RPC for Web services architecture. Future Information Networks 2009, ICFIN Conference, IEEE, pp. 7-10, doi: 10.1109 / ICFIN.2009.5339611 .