rfc1832.html

this gives details of the network programming

   where the constant n is the (static) number of bytes necessary to
   contain the opaque data.  If n is not a multiple of four, then the n
   bytes are followed by enough (0 to 3) residual zero bytes, r, to make
   the total byte count of the opaque object a multiple of four.

          0        1     ...
      +--------+--------+...+--------+--------+...+--------+
      | byte 0 | byte 1 |...|byte n-1|    0   |...|    0   |
      +--------+--------+...+--------+--------+...+--------+
      |<-----------n bytes---------->|<------r bytes------>|
      |<-----------n+r (where (n+r) mod 4 = 0)------------>|
                                                   FIXED-LENGTH OPAQUE

3.10 Variable-length Opaque Data

   The standard also provides for variable-length (counted) opaque data,
   defined as a sequence of n (numbered 0 through n-1) arbitrary bytes
   to be the number n encoded as an unsigned integer (as described
   below), and followed by the n bytes of the sequence.

   Byte m of the sequence always precedes byte m+1 of the sequence, and
   byte 0 of the sequence always follows the sequence's length (count).
   If n is not a multiple of four, then the n bytes are followed by
   enough (0 to 3) residual zero bytes, r, to make the total byte count
   a multiple of four.  Variable-length opaque data is declared in the
   following way:

         opaque identifier<m>;
      or
         opaque identifier<>;

   The constant m denotes an upper bound of the number of bytes that the
   sequence may contain.  If m is not specified, as in the second
   declaration, it is assumed to be (2**32) - 1, the maximum length.
   The constant m would normally be found in a protocol specification.
   For example, a filing protocol may state that the maximum data
   transfer size is 8192 bytes, as follows:

         opaque filedata<8192>;

            0     1     2     3     4     5   ...
         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
         |        length n       |byte0|byte1|...| n-1 |  0  |...|  0  |
         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
         |<-------4 bytes------->|<------n bytes------>|<---r bytes--->|
                                 |<----n+r (where (n+r) mod 4 = 0)---->|
                                                  VARIABLE-LENGTH OPAQUE

   It is an error to encode a length greater than the maximum described
   in the specification.

3.11 String

   The standard defines a string of n (numbered 0 through n-1) ASCII
   bytes to be the number n encoded as an unsigned integer (as described
   above), and followed by the n bytes of the string.  Byte m of the
   string always precedes byte m+1 of the string, and byte 0 of the
   string always follows the string's length.  If n is not a multiple of
   four, then the n bytes are followed by enough (0 to 3) residual zero
   bytes, r, to make the total byte count a multiple of four.  Counted
   byte strings are declared as follows:

         string object<m>;
      or
         string object<>;

   The constant m denotes an upper bound of the number of bytes that a
   string may contain.  If m is not specified, as in the second

   declaration, it is assumed to be (2**32) - 1, the maximum length.
   The constant m would normally be found in a protocol specification.
   For example, a filing protocol may state that a file name can be no
   longer than 255 bytes, as follows:

         string filename<255>;

            0     1     2     3     4     5   ...
         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
         |        length n       |byte0|byte1|...| n-1 |  0  |...|  0  |
         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
         |<-------4 bytes------->|<------n bytes------>|<---r bytes--->|
                                 |<----n+r (where (n+r) mod 4 = 0)---->|
                                                                  STRING

   It is an error to encode a length greater than the maximum described
   in the specification.

3.12 Fixed-length Array

   Declarations for fixed-length arrays of homogeneous elements are in
   the following form:

         type-name identifier[n];

   Fixed-length arrays of elements numbered 0 through n-1 are encoded by
   individually encoding the elements of the array in their natural
   order, 0 through n-1.  Each element's size is a multiple of four
   bytes. Though all elements are of the same type, the elements may
   have different sizes.  For example, in a fixed-length array of
   strings, all elements are of type "string", yet each element will
   vary in its length.

         +---+---+---+---+---+---+---+---+...+---+---+---+---+
         |   element 0   |   element 1   |...|  element n-1  |
         +---+---+---+---+---+---+---+---+...+---+---+---+---+
         |<--------------------n elements------------------->|

                                               FIXED-LENGTH ARRAY

3.13 Variable-length Array

Counted arrays provide the ability to encode variable-length arrays of
homogeneous elements.  The array is encoded as the element count n (an
unsigned integer) followed by the encoding of each of the array's
elements, starting with element 0 and progressing through element n- 1.
The declaration for variable-length arrays follows this form:

         type-name identifier<m>;
      or
         type-name identifier<>;

   The constant m specifies the maximum acceptable element count of an
   array; if m is not specified, as in the second declaration, it is
   assumed to be (2**32) - 1.

           0  1  2  3
         +--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
         |     n     | element 0 | element 1 |...|element n-1|
         +--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
         |<-4 bytes->|<--------------n elements------------->|
                                                         COUNTED ARRAY

   It is an error to encode a value of n that is greater than the
   maximum described in the specification.

3.14 Structure

   Structures are declared as follows:

         struct {
            component-declaration-A;
            component-declaration-B;
            ...
         } identifier;

   The components of the structure are encoded in the order of their
   declaration in the structure.  Each component's size is a multiple of
   four bytes, though the components may be different sizes.

         +-------------+-------------+...
         | component A | component B |...                      STRUCTURE
         +-------------+-------------+...

3.15 Discriminated Union

   A discriminated union is a type composed of a discriminant followed
   by a type selected from a set of prearranged types according to the
   value of the discriminant.  The type of discriminant is either "int",
   "unsigned int", or an enumerated type, such as "bool".  The component
   types are called "arms" of the union, and are preceded by the value
   of the discriminant which implies their encoding.  Discriminated
   unions are declared as follows:

         union switch (discriminant-declaration) {
         case discriminant-value-A:

            arm-declaration-A;
         case discriminant-value-B:
            arm-declaration-B;
         ...
         default: default-declaration;
         } identifier;

   Each "case" keyword is followed by a legal value of the discriminant.
   The default arm is optional.  If it is not specified, then a valid
   encoding of the union cannot take on unspecified discriminant values.
   The size of the implied arm is always a multiple of four bytes.

   The discriminated union is encoded as its discriminant followed by
   the encoding of the implied arm.

           0   1   2   3
         +---+---+---+---+---+---+---+---+
         |  discriminant |  implied arm  |          DISCRIMINATED UNION
         +---+---+---+---+---+---+---+---+
         |<---4 bytes--->|

3.16 Void

   An XDR void is a 0-byte quantity.  Voids are useful for describing
   operations that take no data as input or no data as output. They are
   also useful in unions, where some arms may contain data and others do
   not.  The declaration is simply as follows:

         void;

   Voids are illustrated as follows:

           ++
           ||                                                     VOID
           ++
         --><-- 0 bytes

3.17 Constant

   The data declaration for a constant follows this form:

         const name-identifier = n;

   "const" is used to define a symbolic name for a constant; it does not
   declare any data.  The symbolic constant may be used anywhere a
   regular constant may be used.  For example, the following defines a
   symbolic constant DOZEN, equal to 12.

         const DOZEN = 12;

3.18 Typedef

   "typedef" does not declare any data either, but serves to define new
   identifiers for declaring data. The syntax is:

         typedef declaration;

   The new type name is actually the variable name in the declaration
   part of the typedef.  For example, the following defines a new type
   called "eggbox" using an existing type called "egg":

         typedef egg eggbox[DOZEN];

   Variables declared using the new type name have the same type as the
   new type name would have in the typedef, if it was considered a
   variable.  For example, the following two declarations are equivalent
   in declaring the variable "fresheggs":

         eggbox  fresheggs; egg     fresheggs[DOZEN];

   When a typedef involves a struct, enum, or union definition, there is
   another (preferred) syntax that may be used to define the same type.
   In general, a typedef of the following form:

         typedef <<struct, union, or enum definition>> identifier;

   may be converted to the alternative form by removing the "typedef"
   part and placing the identifier after the "struct", "union", or
   "enum" keyword, instead of at the end.  For example, here are the two
   ways to define the type "bool":

         typedef enum {    /* using typedef */
            FALSE = 0,
            TRUE = 1
         } bool;

         enum bool {       /* preferred alternative */
            FALSE = 0,
            TRUE = 1
         };

   The reason this syntax is preferred is one does not have to wait
   until the end of a declaration to figure out the name of the new
   type.

3.19 Optional-data

   Optional-data is one kind of union that occurs so frequently that we
   give it a special syntax of its own for declaring it.  It is declared
   as follows:

         type-name *identifier;

   This is equivalent to the following union:

         union switch (bool opted) {
         case TRUE:
            type-name element;
         case FALSE:
            void;
         } identifier;

   It is also equivalent to the following variable-length array
   declaration, since the boolean "opted" can be interpreted as the
   length of the array:

         type-name identifier<1>;

   Optional-data is not so interesting in itself, but it is very useful
   for describing recursive data-structures such as linked-lists and
   trees.  For example, the following defines a type "stringlist" that
   encodes lists of arbitrary length strings:

         struct *stringlist {
            string item<>;
            stringlist next;
         };

   It could have been equivalently declared as the following union:

         union stringlist switch (bool opted) {
         case TRUE:
            struct {
               string item<>;
               stringlist next;
            } element;
         case FALSE:
            void;
         };

   or as a variable-length array:

         struct stringlist<1> {

            string item<>;
            stringlist next;
         };

   Both of these declarations obscure the intention of the stringlist
   type, so the optional-data declaration is preferred over both of
   them.  The optional-data type also has a close correlation to how
   recursive data structures are represented in high-level languages
   such as Pascal or C by use of pointers. In fact, the syntax is the
   same as that of the C language for pointers.

3.20 Areas for Future Enhancement

   The XDR standard lacks representations for bit fields and bitmaps,
   since the standard is based on bytes.  Also missing are packed (or
   binary-coded) decimals.

   The intent of the XDR standard was not to describe every kind of data
   that people have ever sent or will ever want to send from machine to
   machine. Rather, it only describes the most commonly used data-types
   of high-level languages such as Pascal or C so that applications
   written in these languages will be able to communicate easily over
   some medium.

   One could imagine extensions to XDR that would let it describe almost
   any existing protocol, such as TCP.  The minimum necessary for this
   are support for different block sizes and byte-orders.  The XDR
   discussed here could then be considered the 4-byte big-endian member
   of a larger XDR family.

4. DISCUSSION

   (1) Why use a language for describing data?  What's wrong with
   diagrams?

   There are many advantages in using a data-description language such
   as XDR versus using diagrams.  Languages are more formal than
   diagrams and lead to less ambiguous descriptions of data.  Languages
   are also easier to understand and allow one to think of other issues
   instead of the low-level details of bit-encoding.  Also, there is a
   close analogy between the types of XDR and a high-level language such
   as C or Pascal.  This makes the implementation of XDR encoding and
   decoding modules an easier task.  Finally, the language specification
   itself is an ASCII string that can be passed from machine to machine
   to perform on-the-fly data interpretation.

   (2) Why is there only one byte-order for an XDR unit?

   Supporting two byte-orderings requires a higher level protocol for
   determining in which byte-order the data is encoded.  Since XDR is
   not a protocol, this can't be done.  The advantage of this, though,
   is that data in XDR format can be written to a magnetic tape, for
   example, and any machine will be able to interpret it, since no
   higher level protocol is necessary for determining the byte-order.

   (3) Why is the XDR byte-order big-endian instead of little-endian?
   Isn't this unfair to little-endian machines such as the VAX(r), which
   has to convert from one form to the other?

   Yes, it is unfair, but having only one byte-order means you have to