RPC ( Remote Procedure Call protocol )

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


• 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.


• Performance:
remote procedures usually operate one or more orders of magnitude slower than local procedure calls.


• Authentication:
since remote procedure calls can be transported over unsecured networks, authentication may be necessary. Authentication prevents one entity from masquerading as some other entity.

Batching
Batching is useful when a client wishes to send an arbitrarily large sequence of call messages to a server. Batching typically uses reliable byte stream protocols (like TCP) for its transport
Broadcast Remote Procedure Calls
In broadcast protocols, the client sends a broadcast call to the network and waits for numerous replies. This requires the use of packet-based protocols (like UDP) as its transport protocol.

• The RPC message

All messages start with a transaction identifier, xid, followed by a two-armed discriminated union. The union's discriminant is a msg_type which switches to one of the two types of the message. The xid of a REPLY message always matches that of the initiating CALL message. NB: The xid field is only used for clients matching reply messages with call messages or for servers detecting retransmissions; the service side cannot treat this id as any type of sequence number.


      struct rpc_msg {

         unsigned int xid;

         union switch (msg_type mtype) {

         case CALL:

            call_body cbody;

         case REPLY:

            reply_body rbody;

         } body;

      };



• Body of an RPC call

In version 2 of the RPC protocol specification must be equal to 2. The fields prog, vers, and proc specify the remote program, its version number, and the procedure within the remote program to be called. After these fields are two authentication parameters: cred (authentication credential) and verf (authentication verifier).


      struct call_body {

         unsigned int rpcvers;       /* must be equal to two (2) */

         unsigned int prog;

         unsigned int vers;

         unsigned int proc;

         opaque_auth  cred;

         opaque_auth  verf;

         /* procedure specific parameters start here */

      };



• Body of a reply to an RPC call
  

  >      union reply_body switch (reply_stat stat) {
  
        case MSG_ACCEPTED:
  
           accepted_reply areply;
  
        case MSG_DENIED:
  
           rejected_reply rreply;
  
        } reply;

  
  
• Reply to an RPC call that was accepted by the server

There could be an error even though the call was accepted. The first field is an authentication verifier that the server generates in order to validate itself to the client. It is followed by a union whose discriminant is an enum accept_stat. The SUCCESS arm of the union is protocol specific. The PROG_UNAVAIL, PROC_UNAVAIL, GARBAGE_ARGS, and SYSTEM_ERR arms of the union are void. The PROG_MISMATCH arm specifies the lowest and highest version numbers of the remote program supported by the server.


      struct accepted_reply {

         opaque_auth verf;

         union switch (accept_stat stat) {

         case SUCCESS:

            opaque results[0];

            /*

             * procedure-specific results start here

             */

          case PROG_MISMATCH:

             struct {

                unsigned int low;

                unsigned int high;

             } mismatch_info;

          default:

             /*

              * Void.  Cases include PROG_UNAVAIL, PROC_UNAVAIL,

              * GARBAGE_ARGS, and SYSTEM_ERR.

              */

             void;

          } reply_data;

      };



• Reply to an RPC call that was rejected by the server

The call can be rejected for two reasons: either the server is not running a compatible version of the RPC protocol (RPC_MISMATCH), or the server rejects the identity of the caller (AUTH_ERROR). In case of an RPC version mismatch, the server returns the lowest and highest supported RPC version numbers. In case of invalid authentication, failure status is returned.


      union rejected_reply switch (reject_stat stat) {

      case RPC_MISMATCH:

         struct {

            unsigned int low;

            unsigned int high;

         } mismatch_info;

      case AUTH_ERROR:

         auth_stat stat;

      };

• RPCBv3

RPCBv3 header format


1	2	3	4	5	6	7	8	Octet
Program Number								1-4
Version Number								5-8
Network ID Length								9-12
Network ID								13-N
Universal Address Length								N+1-N+4
Universal Address								N+5-M



• Program

The program number

• Version

The version number

• Network ID

The network ID

• Universal Address

The universal address



• RPCBV4

Binding protocol version 4 for RPC (RPCv4) is very similar to version 3, but with a few additional parameters.

RPCBv4 header format


1	2	3	4	5	6	7	8	Octet
Program Number								1-4
Version Number								5-8
Network ID Length								9-12
Network ID								13-N
Universal Address Length								N+1-N+4
Universal Address								N+5-M



• Program

The program number

• Version

The version number

• Network ID

The network ID

• Universal Address

The universal address

RPCSEC GSS structure


1	2	3	4	5	6	7	8	Octet
Version								1-4
Procedure								5-8
Sequence Number								9-12
Service								13-16



• Version

The version number

• Procedure

The procedure number

• Sequence Number

The sequence number

• Service

The service number

Example 1: Authentication



The RPC protocol specification defines all three fields to be the following opaque type 

(in the eXternal Data Representation (XDR) language [9]):



          enum auth_flavor {

             AUTH_NONE       = 0,

             AUTH_SYS        = 1,

             AUTH_SHORT      = 2

             /* and more to be defined */

          };



          struct opaque_auth {

             auth_flavor flavor;

             opaque body<400>;

          };

Example 2



Given that a call message was accepted, the following is the status of an attempt to 

call a remote procedure.



          enum accept_stat {

             SUCCESS       = 0, /* RPC executed successfully             */

             PROG_UNAVAIL  = 1, /* remote hasn't exported program        */

             PROG_MISMATCH = 2, /* remote can't support version #        */

             PROC_UNAVAIL  = 3, /* program can't support procedure       */

             GARBAGE_ARGS  = 4, /* procedure can't decode params         */

             SYSTEM_ERR    = 5  /* errors like memory allocation failure */

          };



Reasons why a call message was rejected:

          enum reject_stat {

             RPC_MISMATCH = 0, /* RPC version number != 2          */

             AUTH_ERROR = 1    /* remote can't authenticate caller */

          };



Why authentication failed:

          enum auth_stat {

             AUTH_OK           = 0,  /* success                          */

             /*

              * failed at remote end

              */

             AUTH_BADCRED      = 1,  /* bad credential (seal broken)     */

             AUTH_REJECTEDCRED = 2,  /* client must begin new session    */

             AUTH_BADVERF      = 3,  /* bad verifier (seal broken)       */

             AUTH_REJECTEDVERF = 4,  /* verifier expired or replayed     */

             AUTH_TOOWEAK      = 5,  /* rejected for security reasons    */

             /*

              * failed locally

              */

             AUTH_INVALIDRESP  = 6,  /* bogus response verifier          */

             AUTH_FAILED       = 7   /* reason unknown                   */

          };

Example 3: Service Described in the RPC Language



       program PING_PROG {

             /*

              * Latest and greatest version

              */

             version PING_VERS_PINGBACK {

                void

                PINGPROC_NULL(void) = 0;

                /*

                 * Ping the client, return the round-trip time

                 * (in microseconds). Returns -1 if the operation

                 * timed out.

                 */

                int

                PINGPROC_PINGBACK(void) = 1;

             } = 2;



             /*

              * Original version

              */

             version PING_VERS_ORIG {

                void

                PINGPROC_NULL(void) = 0;

             } = 1;

          } = 1;



          const PING_VERS = 2;      /* latest version */



The first version described is PING_VERS_PINGBACK with two procedures, PINGPROC_NULL 

and PINGPROC_PINGBACK. PINGPROC_NULL takes no arguments and returns no results, 

but it is useful for computing round-trip times from the client to the server and back 

again. By convention, procedure 0 of any RPC protocol should have the same semantics, 

and never require any kind of authentication. The second procedure is used for the 

client to have the server do a reverse ping operation back to the client, and it 

returns the amount of time (in microseconds) that the operation used.  The next 

version, PING_VERS_ORIG, is the original version of the protocol and it does not 

contain PINGPROC_PINGBACK procedure. It is useful for compatibility with old client 

programs, and as this program matures it may be dropped from the protocol entirely.

Example 4: The RPC Language Specification



The RPC language is identical to the XDR language except for the added definition 

of a "program-def" described below.



       program-def:

          "program" identifier "{"

             version-def

             version-def *

          "}" "=" constant ";"



       version-def:

          "version" identifier "{"

              procedure-def

              procedure-def *

          "}" "=" constant ";"



       procedure-def:

          type-specifier identifier "(" type-specifier

            ("," type-specifier )* ")" "=" constant ";"

■ Parent layer
■ Child layer

TCP/UDP

RPC