This overview provides the following information about programming XDR:
XDR not only solves data portability problems, it also permits the reading and writing of arbitrary C language constructs in a consistent and well-documented manner. Therefore, it makes sense to use the XDR library routines even when the data is not shared among machines on a network.
The XDR standard does not depend on machine languages, manufacturers, operating systems, or architectures. This condition enables networked computers to share data regardless of the machine on which the data is produced or consumed. The XDR language permits transfer of data between different computer architectures and has been used to communicate data between such diverse machines as the VAX, IBM, and Cray.
Remote Procedure Call (RPC) uses XDR to establish uniform representations for data types in order to transfer message data between machines. For basic data types, such as integers and strings, XDR provides filter primitives that serialize, or translate, information from the local host's representation to XDR's representation. Likewise, XDR filter primitives deserialize XDR's data representation to the local host's data representation. XDR constructor primitives allow the use of the basic data types to create more complex data types such as arrays and discriminated unions.
The XDR routines that are called directly by remote procedure call routines can be found in the List of XDR Programming References .
The XDR approach to standardizing data representations is canonical. That is, XDR defines representations for a single byte (most significant bit first), a single floating-point representation (IEEE), and so on. Any program running on any machine can use XDR to create portable data by translating its local representation to the XDR standards. Similarly, any program running on any machine can read portable data by translating the XDR standard representations to its local equivalents. The canonical standard completely decouples programs that create or send portable data from those that use or receive portable data.
The advent of a new machine or new language has no effect upon the community of existing portable data creators and users. A new machine can be programmed to convert both the standard representations and its local representations regardless of the local representations of other machines. Conversely, the local representations of the new machine are also irrelevant to existing programs running on other machines. These existing programs can immediately read portable data produced by the new machine, because such data conforms to canonical standards.
Strong precedents exist for XDR's canonical approach. All protocols below layer five of the ISO model, including Transmission Control Protocol (TCP), Internet Protocol (IP), User Datagram Protocol (UDP), Xerox Network Systems (XNS), and Ethernet, are canonical protocols. The advantage of any canonical approach is simplicity. XDR fits into the ISO presentation layer and is roughly analogous in purpose to X.409, ISO Abstract Syntax Notation. The major difference here is that XDR uses implicit typing, while X.409 uses explicit typing. With XDR, a single set of conversion routines need only be written once.
The time spent converting to and from a canonical representation is insignificant, especially in networking applications. When preparing a data structure for transfer, traversing the elements of the structure requires more time than converting the data. In networking applications, additional time is required to move the data down through the sender's protocol layers, across the network, and up through the receiver's protocol layers. Every machine must traverse and copy data structures, regardless of whether conversion is required.
The XDR language is based on the assumption that bytes (eight bits of data or an octet) can be ported to and encoded on media that preserve the meaning of the bytes across the hardware boundaries of data. XDR does not represent bit fields or bit maps. It represents data in blocks of multiples of four bytes (32 bits). The bytes are numbered from 0 to the value of n - 1, where the value (n mod 4) equals 0. They are read from or written to a byte stream in order, such that byte m precedes byte m + 1.
Bytes are ported and encoded from low order to high order in local area networks. Representing data in standardized formats resolves situations that occur when different byte-ordering formats exist on networked machines. This also enables machines with different structure-alignment algorithms to communicate with each other.
See the A Block figure for a representation of a block.
Figure 4-1. A Block. The first line of the diagram shows the following: byte 0, byte 1, dots signifying the bytes between byte 1 and byte n-1, and then byte n-1. After byte n-1 are two residual bytes labeled zero; between these bytes are dots signifying any additional residual bytes would be included. The second line of the diagram shows the byte values of the first line. Byte 0 to byte n-1 is equal to n bytes and the residual zero bytes have a length of r bytes. The last line of the diagram shows an equation that spans the length of the diagram, the equation follows: n+r (where (n+r) mod 4 = 0) identifies the length.
In a graphics box illustration, each box is delimited by a + (plus sign) at the four corners and by vertical bars and dashes. Each box depicts a byte. The three sets of . . . (ellipsis) between boxes indicate 0 or more additional bytes, where required.
The XDR standard currently lacks representations for bit fields and bit maps because the standard is based on bytes. Packed, or binary-coded, decimals are also missing.
The XDR standard describes only the most commonly used data types of high-level languages, such as C or Pascal. This standard enables applications that are written in these languages to communicate easily.