Protocols for Interworking: XNFS, Version 3W
Copyright © 1998 The Open Group
RPC Interface to UDP Transport Services
The purpose of this chapter is to describe how
protocols defined as part of XNFS interface with the
These protocols are designed to be machine, operating system,
network architecture and transport protocol-independent.
The independence is achieved through the use of Remote Procedure
Call (RPC) primitives built on top of an External Data Representation
This specification will deal with the interface between RPC and the
Though RPC is designed to be transport-independent,
this specification will only deal with the implementation of
RPC on top of UDP/IP.
It should also be noted that this specification contains no mention of the
programmatic interface to UDP, as this is implementation-specific.
RPC and Transport Requirements
The RPC protocol is independent of transport protocols; that is,
RPC does not care how a message is passed from one process to another.
The protocol deals only with specification and
interpretation of messages.
It is important to note that RPC does not try to implement any
kind of reliability, and that the application must be aware of the
type of transport protocol underneath RPC.
If the application knows it is
running on top of a reliable transport such as TCP/IP, then most
of the work is already done for it.
If, however, it is
running on top of an unreliable transport such as UDP/IP, the application
must implement its own retransmission and time-out policy, as the RPC
layer does not provide this service.
Because of transport independence, the RPC protocol does not attach
specific semantics to the remote procedures or their execution.
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/IP.
If an application retransmits RPC messages after short time-outs, the
only thing it can infer if it receives no reply is that the
procedure was executed zero or more times.
If it does receive a reply, then it can infer that the procedure
was executed at least once.
UDP as a Transport Protocol
UDP (User Datagram Protocol) is a datagram-based protocol that
relies on the Internet Protocol (IP) transport for packet delivery.
Because it is a datagram service without any connection, retransmission
or ordering information, UDP delivery is unreliable.
Although packets generally reach their destination, it cannot be
They may be lost, duplicated or arrive out of order.
A UDP packet consists of a UDP header followed by data.
The whole is passed to the IP layer for transmission.
The IP layer delivers the data packet to the correct host specified by the
destination IP address and the UDP layer targets the specific
destination within the host, specified by a destination port number.
Full specifications of the UDP and IP protocols are contained in
RFC 768 User Datagram Protocol and RFC 791 Internet Protocol
References to RFCs
The RPC Request
A UDP packet containing an RPC request would be as follows:
|Data octets ........
- Source Port
The 16-bit port number the RPC client is using.
- Destination Port
The 16-bit port number on the destination host at which the
RPC server is listening for requests.
This must be specified by the protocol layer above UDP.
The NFS and Portmap servers use
fixed UDP ports; all others request a free port from the
transport provider and register this port with the Portmap
service; RPC clients will interrogate the Portmap service to
determine the port to be used to reach the intended RPC server.
The number of bytes in the packet.
This includes the UDP header and the data (RPC packet in this case).
- The checksum is the 16-bit one's complement
of the one's complement sum of all 16-bit words in the
pseudo-header, UDP header and raw data.
The UDP pseudo-header consists of the source and destination
IP addresses, the Internet Protocol Number for UDP (17 decimal)
and the UDP length (see RFC 768).
An implementation may choose not to compute a UDP checksum when
transmitting a packet, in which case it must set the checksum
field to zero.
- Data Octets
Provided by the protocol layer above UDP.
In this case, this is the RPC request itself.
In addition, the destination of the UDP packet must be specified as an
The RPC Reply
Once the RPC request has been received and processed by the server
program, the server must construct a reply packet and send it
to the client. The only exception is for
such as those used by the Network Lock Manager (see
NLM Procedures, for more details). In that case the server need
not send an RPC reply packet. Instead, the server sends the
response, if there is one, as a new RPC from the server to the client.
(The client need not send an RPC reply to this second RPC). New
protocols are strongly discouraged from using asynchronous
In most implementations, the IP protocol layer will provide the
upper-layer protocols with the source and destination IP addresses of the
This information can be used to construct the return packet.
The source port and IP address from the RPC request become the
destination port and IP address of the RPC reply.
The data in the UDP packet is the RPC reply which will contain
results and return data from the RPC server program.
Receiving a UDP Reply Packet
After sending an RPC request, the client program waits for the
reply. This may be achieved in several ways; by issuing a blocking
request to receive a packet, or by waiting for an asynchronous
notification from the transport layer. The program may also do
other processing while waiting for the reply. In any case, the
application must be able to control how long it waits for a
reply before it times-out the RPC.
In either case the
application must be able to control how long it waits for a reply
before it times-out the RPC.
An implementation must consider all of the
ways in which the wait may be terminated.
If it is impossible
to send the request to the server for some reason (if the server
program has failed, or the server system is inaccessible), it is usually
the case that a notification of some kind is returned to the client
system, using the ICMP protocol.
It is desirable that this condition
can be signalled to the client application so that it need not
wait for the request to time out.
In addition, the reception
of duplicate or delayed packets may mean that a packet is received
which has the correct transport addressing but is rejected at the
RPC layer (due, for example, to an invalid transaction ID).
The transport layer must therefore ensure that packets
can be queued in some fashion so that valid replies are not lost.
Since UDP is a connectionless transport, no explicit actions are required to
terminate the client/server relationship, although particular implementations
may require the freeing of data structures and so on.
Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy
of this publication.