RPC: Remote Procedure Call Protocol specification: Version 2
RFC 1057

Document Type RFC - Informational (June 1988; No errata)
Obsoletes RFC 1050
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1057 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                             Sun Microsystems, Inc.
Request For Comments: 1057                                     June 1988
Obsoletes: RFC 1050

                       RPC: Remote Procedure Call
                         Protocol Specification
                               Version 2

STATUS OF THIS MEMO

   This RFC describes a standard that Sun Microsystems and others are
   using, and is one we wish to propose for the Internet's
   consideration.  This memo is not an Internet standard at this time.
   Distribution of this memo is unlimited.

1. INTRODUCTION

   This document specifies version two of the message protocol used in
   Sun's Remote Procedure Call (RPC) package.  The message protocol is
   specified with the eXternal Data Representation (XDR) language [9].
   This document assumes that the reader is familiar with XDR.  It does
   not attempt to justify remote procedure calls systems or describe
   their use.  The paper by Birrell and Nelson [1] is recommended as an
   excellent background for the remote procedure call concept.

2. TERMINOLOGY

   This document discusses clients, calls, servers, replies, services,
   programs, procedures, and versions.  Each remote procedure call has
   two sides: an active client side that sends the call to a server,
   which sends back a reply.  A network service is a collection of one
   or more remote programs.  A remote program implements one or more
   remote procedures; the procedures, their parameters, and results are
   documented in the specific program's protocol specification (see
   Appendix A for an example).  A server may support more than one
   version of a remote program in order to be compatible with changing
   protocols.

   For example, a network file service may be composed of two programs.
   One program may deal with high-level applications such as file system
   access control and locking.  The other may deal with low-level file
   input and output and have procedures like "read" and "write".  A
   client of the network file service would call the procedures
   associated with the two programs of the service on behalf of the
   client.

   The terms client and server only apply to a particular transaction; a

Sun Microsystems                                                [Page 1]
RFC 1057            Remote Procedure Call, Version 2           June 1988

   particular hardware entity (host) or software entity (process or
   program) could operate in both roles at different times.  For
   example, a program that supplies remote execution service could also
   be a client of a network file service.  On the other hand, it may
   simplify software to separate client and server functionality into
   separate libraries or programs.

3. THE RPC MODEL

   The Sun RPC protocol is based on the remote procedure call model,
   which is similar to the local procedure call model.  In the local
   case, the caller places arguments to a procedure in some well-
   specified location (such as a register window).  It then transfers
   control to the procedure, and eventually regains control.  At that
   point, the results of the procedure are extracted from the well-
   specified location, and the caller continues execution.

   The remote procedure call model is similar.  One thread of control
   logically winds through two processes: the caller's process, and a
   server's process.  The caller process first sends a call message to
   the server process and waits (blocks) for a reply message.  The call
   message includes the procedure's parameters, and the reply message
   includes the procedure's results.  Once the reply message is
   received, the results of the procedure are extracted, and caller's
   execution is resumed.

   On the server side, a process is dormant awaiting the arrival of a
   call message.  When one arrives, the server process extracts the
   procedure's parameters, computes the results, sends a reply message,
   and then awaits the next call message.

   In this model, only one of the two processes is active at any given
   time.  However, this model is only given as an example.  The Sun RPC
   protocol makes no restrictions on the concurrency model implemented,
   and others are possible.  For example, an implementation may choose
   to have RPC calls be asynchronous, so that the client may do useful
   work while waiting for the reply from the server.  Another
   possibility is to have the server create a separate task to process
   an incoming call, so that the original server can be free to receive
   other requests.

   There are a few important ways in which remote procedure calls differ
   from local procedure calls:

   1. Error handling: failures of the remote server or network must be
   handled when using remote procedure calls.

   2. Global variables and side-effects: since the server does not have

Sun Microsystems                                                [Page 2]
RFC 1057            Remote Procedure Call, Version 2           June 1988
Show full document text