Lecture 24: Data Formats and Encoding

Example: Integers in Unix RPC

We assume that an integer is 32 bits (4 bytes) in length. There are (basically) two ways in which an integer can be stored in the memory of a computer: with the Least Significant Byte in the lowest numbered address (so-called Little-Endian format), or with the Most Significant Byte at that position (Big-Endian). The Intel (and compatible) range of processors is Little-Endian, as were the Digital range of CPUs, and virtually all others (past and present) are Big-Endian.

Take, for example, the integer 1003421_dec (000f4f9d_hex). We assume that this integer is stored at address X in memory. In the Little-Endian storage, shown at left, the byte at the "address of" the integer has value 9d_hex. In Big-Endian storage, shown at right, the byte at the "address of" the integer is 00_hex.

Software which desires to send (as raw bytes) such an integer as a parameter to a remote procedure cannot simply read the bytes from memory and transmit them, because the remote machine might use a different byte-order. In XDR, the solution is to (transparently) convert integers from their native format to Big-Endian format for transmission, and transparently convert them back at the other end to the appropriate native format. Hence, two non-Intel machines will incur no "translation overhead", whereas two Intel machines communicating will be required to convert the order at each end of the communications.

It will be readily seen that, as mentioned, XDR uses canonical forms for data transmission. More importantly, the required conversions occur within the RPC sub-system, so the programmer never needs to be aware of them. Their operation is transparent.

Lecture 24: Data Formats and Encoding -- A Philosophy Lecture

previous | start | next