RPC Interface to UDP Transport Services

Introduction

The purpose of this chapter is to describe how protocols defined as part of XNFS interface with the underlying transport. 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 (XDR). This specification will deal with the interface between RPC and the underlying transport.

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 guaranteed. 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 (see References to RFCs ).

RPC Interface

The RPC Request

A UDP packet containing an RPC request would be as follows:

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.

Length

The number of bytes in the packet. This includes the UDP header and the data (RPC packet in this case).

Checksum

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 IP address.

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 asynchronous calls, such as those used by the Network Lock Manager (see NLM Procedures 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 calls.

In most implementations, the IP protocol layer will provide the upper-layer protocols with the source and destination IP addresses of the request packet. 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.

Closing

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.