The features of Remote Procedure Call (RPC) include batching calls, broadcasting calls, callback procedures, and using the select subroutine. Batching allows a client to send an arbitrarily large sequence of call messages to a server. Broadcasting allows a client to send a data packet to the network and wait for numerous replies. Callback procedures permit a server to become a client and make an RPC callback to the client's process. The select subroutine examines the I/O descriptor sets whose addresses are passed in the readfds, writefds, and exceptfds parameters to see if some of their descriptors are ready for reading or writing, or have an exceptional condition pending. It then returns the total number of ready descriptors in all the sets.
RPC is also used for the rcp program on Transmission Control Protocol/Internet Protocol (TCP/IP). See "rcp Process on TCP Example".
Batching allows a client to send an arbitrarily large sequence of call messages to a server. Batching typically uses reliable byte stream protocols, such as TCP/IP, for its transport. When batching, the client never waits for a reply from the server, and the server does not send replies to batched requests. Normally, a sequence of batch calls should be terminated by a legitimate, nonbatched RPC to flush the pipeline.
The RPC architecture is designed so that clients send a call message and then wait for servers to reply that the call succeeded. This implies that clients do not compute while servers are processing a call. However, the client may not want or need an acknowledgment for every message sent. Therefore, clients can use RPC batch facilities to continue computing while they wait for a response.
Batching can be thought of as placing RPC messages in a pipeline of calls to a desired server. Batching assumes the following:
For a client to use batching, the client must perform remote procedure calls on a TCP/IP-based transport. Batched calls must have the following attributes:
Since the server sends no message, the clients are not notified of any failures that occur. Therefore, clients must handle their own errors.
Since the server does not respond to every call, the client can generate new calls that run parallel to the server's execution of previous calls. Furthermore, the TCP/IP implementation can buffer many call messages, and send them to the server with one write subroutine. This overlapped execution decreases the interprocess communication overhead of the client and server processes as well as the total elapsed time of a series of calls. Batched calls are buffered, so the client should eventually perform a nonbatched remote procedure call to flush the pipeline with positive acknowledgment.
In broadcast RPC-based protocols, the client sends a broadcast packet to the network and waits for numerous replies. Broadcast RPC uses only packet-based protocols, such as User Datagram Protocol/Internet Protocol (UDP/IP), for its transports. Servers that support broadcast protocols respond only when the request is successfully processed and remain silent when errors occur. Broadcast RPC requires the RPC port mapper service to achieve its semantics. The portmap daemon converts RPC program numbers into Internet protocol port numbers. See "Broadcasting a Remote Procedure Call Example".
The main differences between broadcast RPC and normal RPC are as follows:
Occasionally, the server may need to become a client by making an RPC callback to the client's process. To make an RPC callback, the user needs a program number on which to make the call. The program number is dynamically generated and should be in the transient range, 0x40000000 to 0x5fffffff. See "RPC Callback Procedures Example" for more information.
The select subroutine checks the specified file descriptors and message queues to see if they are ready for reading (receiving) or writing (sending), or if they have an exceptional condition pending. A select procedure allows the server to interrupt an activity, check for data, and then continue processing the activity. For example, if the server processes RPC requests while performing another activity that involves periodically updating a data structure, the process can set an alarm signal to notify the server before calling the svc_run routine. However, if the current activity is waiting on a file descriptor, the call to the svc_run routine does not work. See "Using the select Subroutine Example" for more information.
A programmer can bypass the svc_run routine and call the svc_getreqset routine directly. It is necessary to know the file descriptors of the sockets associated with the programs being waited on. The programmer can have a select statement that waits on both the RPC socket and specified descriptors.
Note: The svc_fds parameter is a bit mask of all the file descriptors that RPC is using for services. It can change each time an RPC library routine is called because descriptors are continually opened and closed. TCP/IP connections are an example.