Skip Navigation Links | |
Exit Print View | |
ONC+ Developer's Guide Oracle Solaris 11.1 Information Library |
1. Introduction to ONC+ Technologies
4. Programmer's Interface to RPC
5. Advanced RPC Programming Techniques
6. Porting From TS-RPC to TI-RPC
7. Multithreaded RPC Programming
8. Extensions to the Oracle Solaris RPC Library
B. RPC Protocol and Language Specification
Hyper Integer and Unsigned Hyper Integer
Double-Precision Floating Point Encoding
Quadruple-Precision Floating Point
Quadruple-Precision Floating Point Encoding
External data representation (XDR) is a standard for the description and encoding of data. The XDR protocol is useful for transferring data between different computer architectures and has been used to communicate data between very diverse machines. XDR fits into the ISO reference model's presentation layer (layer 6) and is roughly analogous in purpose to X.409, ISO Abstract Syntax Notation. The major difference between the two is that XDR uses implicit typing, while X.409 uses explicit typing.
XDR uses a language to describe data formats and can only be used to describe data. It is not a programming language. This language enables you to describe intricate data formats in a concise manner. The XDR language is similar to the C language. Protocols such as RPC and NFS use XDR to describe the format of their data.
The XDR standard assumes that bytes, or octets, are portable and that a byte is defined to be 8 bits of data.
This appendix uses graphic box notation for illustration and comparison. In most illustrations, each box depicts a byte. The representation of all items requires a multiple of 4 bytes (or 32 bits) of data. The bytes are numbered 0 through n -1. The bytes are read or written to some byte stream such that byte m always precedes byte m+1. The n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count a multiple of four. Ellipses (...) between boxes show zero or more additional bytes where required, as shown in the following illustration.
Choosing the XDR block size requires a tradeoff. Choosing a small size such as 2 makes the encoded data small, but causes alignment problems for machines that are not aligned on these boundaries. A large size such as 8 means the data is aligned on virtually every machine, but causes the encoded data to grow too large. Four was chosen as a compromise. Four is big enough to support most architectures efficiently.
This basic block size of 4 does not mean that the computers cannot utilize standard XDR, just that they do so at a greater overhead per data item than 4-byte (32-bit) architectures. Four is also small enough to keep the encoded data restricted to a reasonable size.
The same data should encode into an equivalent result on all machines so that encoded data can be compared or checksummed. So, variable-length data must be padded with trailing zeros.