. 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 transport and application retrans- mits RPC messages after short timeouts and receives no reply, then it can be inferred that the procedure was executed zero or more times. If a reply is received, it can be inferred that the procedure was executed at least once. The transaction ID is used Fundamentals of EMS, NMS and OSS/BSS primarily by the client RPC layer to match replies to requests and the client application may choose to reuse its previous transaction ID when retransmitting a request. The server cannot examine this ID in any other way except as a test for equality. A server takes advantage of the transaction ID that is packaged with every RPC request to ensure that the procedure is executed at least once. The transaction ID can also ensure that a previously granted request from a client does not get granted again. If the application runs on a reliable transport, it can infer that the procedure was executed exactly once from the reply message. If no reply message is received, it cannot assume the remote procedure was not executed. An application needs tim- eouts and reconnection to handle server crashes even with a connection oriented protocol like TCP. 27.3.2 Presentation The XDR is a popular presentation layer in implementing RPC applications. XDR can be used to transfer data between diverse computer architectures and enables communication between diverse machines like Sun Solaris, VAX, or AIX from IBM. For communication between heterogeneous systems, a common f