d once the execu- tion is complete, the response is sent to the client. So the client makes a procedure call sending a request to the server and waits. The client thread is blocked from RPC Programming RPC client Send request RPC server Call RPC Execute function service Return response Figure 27.1 RPC Client-server model. processing until either a reply is received or the request times out and the client program continues as soon as the RPC call is completed. A remote procedure is identified by a combination of program number, version number, and procedure number. In a group of related remote procedures, each remote procedure is identified by a unique procedure number in the program. The program is further identified using the program number, which is unique. Each version of a program consists of a collection of procedures that are available to be called remotely. Multiple versions of an RPC protocol can be made available using the version numbers. In order to develop an RPC application, first the protocol for the client-server communication needs to be defined. This is followed by the development of the client program and the server program. The programming aspects to be looked into for RPC development are discussed in this chapter. 27.3 RPC Concepts 27.3.1 Transport RPC protocol is a message protocol that is independent of the transport protocol and is specified using XDR language. The RPC protocol concerns only with the specification and interpretation of messages. Reliability of communication is not guaranteed with RPC and this is dependent on the transport protocol. Most of the issues in reliability can be eliminated if the application runs on a connection oriented transport such as TCP/IP. When an unreliable connectionless transport like UDP is used, the application needs to implement its own retransmission and timeout policy. The RPC protocol does not attach specific semantics to the remote procedures or their execution SO as to ensure transport independence. Consider RPC running on top of an unreliable tr