RPC: Remote Procedure Call Version 2

Posted on |

RPC: Remote Procedure Call Version 2

This document is about 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.


In this document, we will discuss 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.  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 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.


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 access to the client’s address space, hidden arguments cannot be passed as global variables or returned as side effects.
  3. Performance:  remote procedures usually operate one or more orders of magnitude slower than local procedure calls.
  4. Authentication: since remote procedure calls can be transported over insecure networks, authentication may be necessary.
The conclusion is that even though there are tools to automatically generate client and server libraries for a given service, protocols must still be designed carefully.

top up  now Digicel



The RPC protocol can be implemented on several different transport protocols.  The RPC protocol does not care how a message is passed from one process to another, but only with specification and interpretation of messages.  On the other hand, the application may wish to obtain information about (and perhaps control over) the transport layer through an interface.


For example, the transport protocol may impose a restriction on the maximum size of RPC messages, or it may be stream-oriented like TCP with no size limit.  The client and server must agree on their transport protocol choices, through a mechanism.


It is important to point out that RPC does not try to implement any kind of reliability and that the application may need to be aware of the type of transport protocol underneath RPC.  If it knows it is running on top of a reliable transport such as TCP, then most of the work is already done for it.  On the other hand, if it is running on top of an unreliable transport such as UDP, it must implement its own time-out, retransmission, and duplicate detection policies as the RPC layer does not provide these services.


Because of transport independence, the RPC protocol does not attach specific semantics to the remote procedures or their execution requirements.  Semantics can be inferred from (but should be explicitly specified by) the underlying transport protocol.  For example, consider RPC running on top of an unreliable transport such as UDP.  If an application retransmits RPC call messages after timeouts, and does not receive a reply, it cannot infer anything about the number of times the procedure was executed.  If it does receive a reply, then it can infer that the procedure was executed at least once.


A server may wish to remember previously granted requests from a client and not regrant them in order to insure some degree of execute-at-most-once semantics.  A server can do this by taking advantage of the transaction ID that is packaged with every RPC message.  The main use of this transaction is by the client RPC layer in matching replies to calls.  However, a client application may choose to reuse its previous transaction ID when retransmitting a call.  The server may choose to remember this ID after executing a call and not execute calls with the same ID in order to achieve some degree of execute-at-most-once semantics.  The server is not allowed to examine this ID in any other way except as a test for equality.


On the other hand, if using a “reliable” transport such as TCP, the application can infer from a reply message that the procedure was executed exactly once, but if it receives no reply message, it cannot assume the remote procedure was not executed.  Note that even if a connection-oriented protocol like TCP is used, an application still needs time-outs and reconnection to handle server crashes.

There are other possibilities for transports besides datagram- or connection-oriented protocols.  For example, a request-reply protocol such as VMTP is perhaps a natural transport for RPC.  The Sun RPC package currently uses both TCP and UDP transport protocols, with experimentation underway on others such as ISO TP4 and TP0.


The act of binding a particular client to a particular service and transport parameters is NOT part of this RPC protocol specification. This important and necessary function is left up to some higher-level software. Implementors could think of the RPC protocol as the jump-subroutine instruction (“JSR”) of a network; the loader (binder) makes JSR useful, and the loader itself uses JSR to accomplish its task. Likewise, the binding software makes RPC useful, possibly using RPC to accomplish this task.


The RPC protocol provides the fields necessary for a client to identify itself to a service, and vice-versa, in each call and reply message.  Security and access control mechanisms can be built on top of this message authentication.  Several different authentication protocols can be supported.  A field in the RPC header indicates which protocol is being used.

Product Collection


The RPC protocol must provide for the following:
  1. Unique specification of a procedure to be called.
  2. Provisions for matching response messages to request messages.
  3. Provisions for authenticating the caller to service and vice-versa.
Besides these requirements, features that detect the following are worth supporting because of protocol roll-over errors, implementation bugs, user error, and network administration:
  1. RPC protocol mismatches.
  2. Remote program protocol version mismatches.
  3. Protocol errors (such as misspecification of a procedure’s parameters).
  4. Reasons why remote authentication failed.
  5. Any other reasons why the desired procedure was not called.


As previously stated, authentication parameters are opaque but open-ended to the rest of the RPC protocol.  This section defines some “flavors” of authentication implemented at (and supported by) Sun.  Other sites are free to invent new authentication types, with the same rules of flavor number assignment as there is for program number assignment.

  1. Null Authentication
  2. UNIX Authentication
  3. DES Authentication


Books you may interested

Books on RPC  Books on RPC  Books on RPC  Books on RPC  Books on RPC  Books on RPC 


atennisoutlet.com  atennisoutlet.com  atennisoutlet.com  atennisoutlet.com  atennisoutlet.com  atennisoutlet.com  atennisoutlet.com  atennisoutlet.com  atennisoutlet.com  atennisoutlet.com 



How to Start a T-Shirt Business with Customon


banggood.com     BerrryLook.com!     mycaseco.com 


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.