Remote Procedure Call (RPC)
Sun Microsystem's RPC is designed to suit network programming i.e. where program modules are called from different machines.
RPC underwrites Sun's Protocol suite.
Network File System (NFS)
is a network file sharing system application that is a good example
of how RFC can be used. The original version of RPC was defined in RFC 1050
Version 2 of RPC is defined in RFC 1057
The Open Network Computing (ONC)
RPC version 2
is however, defined in RFC 1831
RPC provides a central point for applications to apply for TCP/UDP ports. Rather than applications having to
be tied to particular ports, RPC provides a port mapping service whereby RPC assigns port numbers above 1024 to
applications that are written to request RPC for ports. The lookup services that can be used for this include PORTMAPPER
and are described in RFC 1833
has a fixed port (either UDP or TCP) number 111
to which an application (RPC service) makes a call to gain a port number to use.
This lookup service program must be started first and remain operational throughout the runtime of the application.
RPC works on a Request-Reply basis i.e. a program will request a port and then block whilst it waits for a reply.
Meanwhile other programs will be able to make requests to the Portmapper.
RPC data is encoded using eXternal Data Representation (XDR)
as defined in
, which defines how integers, floating point numbers and strings
are represented. This Presentation Layer protocol enables different computers with different operating systems to interact seamlessly.
There is no formal message header or protocol system for XDR.
XDR uses an 8-bit byte, with the lower bytes being the most significant. The RFC defines that all integer
data types are converted to 4-byte integers, (there is also available an extended 64-bit hyperinteger format). IEEE 32-bit
formats are used for floating-point numbers, where the mantissa is the lower 23 bits, the exponent takes 8 bits,
and the sign of the number is 1 bit. Where data takes less than 4 bytes for any type, padding is added to ensure 4-byte lengths
RPC provides methods for authenticating procedure calls from one machine to another e.g. NFS can be used where
Unix user and Group IDs are sent as the authentication process.
RPC sits at the Presentation Layer of the OSI model.
As well as Applications such as Network File system (NFS)
RPC provides support for PortMapper, Mount and NIS
Whereas a Local Procedure call on a computer would perhaps use memory registers to hook into data, procedures or other sub-routines,
The Remote Procedure Call operates in a similar manner but uses ports and accesses sub-routines across a network. The operation
is summarised as follows:
- The calling process sends a Call Message to the server process and blocks whilst it waits for a reply.
This Call Message includes the parameters required for entry into the remote procedure and can be to an IP broadcast
address, a multicast address or a specific IP address.
- The server process calculates the results and sends a Reply Message with the results.
- The results are extracted and the caller continues with the program.
There are therefore two types of messages, a Call Message and a Reply Message.
The RPC UDP and TCP frames have a structure similar to the following example:
The UDP version is actually an NFS frame that uses Unix for authentication (hence the extra fields) and does not use
an authentication verifier.
The RPC Call message has the following fields:
- Transaction ID - matches RPC requests and replies.
- Sending Direction Indicator
- RPC version number - currently the version is 4 for connectionless RPC (using UDP) and 5 for connection-oriented
RPC. An extra field is added for connection-oriented RPC for the minor protocol version ('0' or '1').
- Remote Program Number - issued by Sun (email@example.com)
- Remote Program Version Number - version of the program
- Remote Procedure Number - the number of the procedure being called. This number matches the Requests
and the Replies and is a 4-byte field containing an 8 digit hexadecimal number.
- Remote Protocol Number - the first 4 least significant bits are used for this. The other bits are reserved.
Sun has control over program numbers 0x00000000 to 0x1fffffff. The range 0x20000000 to 0x3fffffff is
for user use when testing new applications. Other ranges above are given out in blocks of 0x20000000.
The following table lists some of the more common Program call numbers that Sun have assigned in their range:
||portmap sunrpc. Manages use of transport ports. Other Lookup services could be used here.
||Network file system.
||ypprog. Yellow pages directory service.
||Yellow pages binding service.
||Yellow pages password server.
||Disk quota manager.
||3270 mapping service.
||Remote job entry mapping service.
||Remote database access.
||Alice office automation program.
||Local lock manager.
||Network lock manager.
||X.25 INR protocol.
||Status monitor 1.
||Status monitor 2.
||Boot parameters service.
||Yellow pages update service.
||Secure login service.
||NFS network forwarding service.
||NFS forwarding transmitter.
||Translucent file service.
||NSE activate process.
||Yellow Pages Transfer.
||PC password authorization.
||Pyramid lock service.
||Pyramid Sys5 service.
||CV CADDS images.
||ADT file locking service.
There are also the following authentication parameters:
- 0 - (Null) Not used and the authentication fields have zero length.
- 1 - (UNIX) UNIX user and group IDs. If this is the type authentication being used then additional parameters
such as the System Name, User ID and Group ID. This is used by NFS.
- 2 - (Short) Shorthand code used, generated by the client
- 3 - (DES) Data encryption standard used by secure NFS.
describes authentication mechanisms for RPC.
describes the RPCSEC_GSS ONC RPC security flavor.
describes Generic Security Service Application Program Interface.
Reply Messages can contain the following messages:
- call successful - Call completed with no errors.
- program unknown - Program number was not found.
- bad program ver - Program version was not found.
- proced unknown - Program procedure was not found.
- bad parameters - Invalid call parameters (arguments) were found.
- bad RPC version - RPC Version not supported.
- bad credentials - Invalid call credentials supplied.
- restart session - Request to begin a new session.
- bad verifier - Invalid verifier was supplied.
- verify rejected - Verifier has expired or was re-used.
- failed security - Caller has insufficient privileges.
Any RPC service is identified by its RPC program number, the version number
and the transport address (i.e. the TCP or UDP port).
Port Mapper (PMAP version 2) is most often used as a lookup service where
the server programs dynamically register their transport addresses (ports).
Client programs consult the lookup service vis the well-known port (111) and
are given the temporary ports to use to access the server programs.
There is also however, RPCBIND (versions 3 and 4)
that is newer and can also be used as a lookup service but is not tied to just
TCP and UDP, as PMAP is. Instead RPCBIND can use any transport and uses
an ASCII string in Universal Address Format instead of a TCP/UDP port.
Anyway, as mentioned before, the Port Mapper protocol PMAP uses TCP/UDP port 111 and allocates ports above
1024 to applications as and when the client requests it. The client first talks to the Port Mapper before
it talks to the application, which is why Port Mapper must be up and running first.
The following list illustrates the different types of PMAP frames:
- no operation - NULL, Performs no operation.
- set port number - Attempt to register an application.
- unset port numb - Attempt to unregister an application.
- get port number - Requests registered port number.
- get all ports - DUMP, Requests all registered ports.
- call program - Direct call to a registered application.
- port assigned - Registers an application to a port.
- port unassigned - Unregisters an application.
- give port number - Informs client of registered port.
- give all ports - Informs client of all registered ports.
- program called - Returns information from called program
The following parameters are found in a PMAP frame:
- Assigned port for the particular application
- Application Program Number
- Program Version Number
- Transport Layer protocol being usedby the application e.g. TCP, UDP etc.
- Procedure Number