Enhancement of The Sun RPC Library

In previous versions of the Sun RPC library, most requests were sent by two-way messaging. In two-way messaging, the client thread waits until it gets an answer from the server before continuing processing. If the client thread does not receive a reply from the server within a certain period of time, a time-out occurs. This client thread cannot send a second request until the first request is executed or until a time-out occurs. This messaging method is illustrated in Figure 1–1.

Figure 1–1 Two-Way Messaging

Previous versions of the Sun RPC library contain a second method of messaging called batching. In this method, client requests are held in a queue until a group of requests can be processed at the same time. This is a form of one-way messaging. See “The Programmer's Interface to RPC” in ONC+ Developer's Guide for further details.

The new features of the Sun RPC library enhance the library's performance as follows:

1. One-way messaging, where when a client sends a request to a server, the client does not wait for a reply from the server and is free to continue processing when the transport layer accepts the request. If you choose to send a message by one-way messaging, rather than two-way messaging, you gain processing time. See Figure 1–2 for an illustration of one-way messaging.

   Figure 1–2 One-Way Messaging

   
   

2. Non-blocking I/O, where there is an additional buffer between the client and the transport layer. Figure 1–3 describes the case where you choose the non-blocking argument of the I/O mode and the transport layer queue is full. In this situation, requests cannot go into the transport layer queue and are placed in the buffer. The client does not wait for the transport layer to accept the request but is free to continue processing when the request is accepted by the buffer. By using non-blocking I/O you gain further processing time as compared to two-way and one-way messaging. The client can send requests in succession without being blocked from processing.

   Figure 1–3 Non-Blocking Messaging

   
   

3. Client connection closure callback, where, for connection-oriented transport the server can detect that the client has disconnected, and the server can take the necessary action to recover from transport errors. Transport errors occur when a request arrives at the server, or when the server is waiting for a request and the connection is closed.

4. User file descriptor callbacks, which enables an RPC server to receive non-RPC requests as well as RPC requests. With previous versions of the Sun RPC library you can use a server to receive both RPC calls and non-RPC file descriptors only if you write your own server loop, or use a separate thread to contact the socket API.

   With user file descriptor callbacks, RPC servers handle client requests through a run loop using svc_run(). See the svc_run(3NSL) man page for further information. The server enters the run loop at the start of the server connection, and exits the run loop at the end of the connection. When you make an RPC call but do not have user file descriptor callbacks you are blocked from receiving non-RPC requests.