previous | start | next

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, and virtually all others are Big-Endian.
 
Little Endian vs Big Endian storage of integer Take, for example, the integer 1003421dec (000f4f9dhex). 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 9dhex. In Big-Endian storage, shown at right, the byte at the "address of" the integer is 00hex.
 
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 Copyright © 2002 P.Scott, La Trobe University Bendigo.

previous | start | next