ansport 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 format that is understood by both systems is required. XDR enables RPC to handle arbitrary data structures, in a machine independent manner regardless of the byte order or structure layout conventions used. This machine dependency is eliminated by con- verting the data structures to XDR before sending (see Figure 27.2). Using XDR, any program running on any machine can create portable data by translating its local representation into the XDR representation and vice versa. Data conversion with XDR involves two tasks. They are: Serializing: This is the p