xdr.rfc.ms

RTEMS (Real-Time Executive for Multiprocessor Systems) is a free open source real-time operating sys

.IX XDR futures
.LP
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.
.LP
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.
.LP
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.
.NH 1
\&Discussion
.sp 2
.NH 2
\&Why a Language for Describing Data?
.IX XDR language
.LP
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.
.NH 2
\&Why Only one Byte-Order for an XDR Unit?
.IX XDR "byte order"
.LP
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.
.NH 2
\&Why does XDR use Big-Endian Byte-Order?
.LP
Yes, it is unfair, but having only one byte-order means you have to
be unfair to somebody.  Many architectures, such as the Motorola
68000 and IBM 370, support the big-endian byte-order.
.NH 2
\&Why is the XDR Unit Four Bytes Wide?
.LP
There is a tradeoff in choosing the XDR unit size.  Choosing a small
size such as two makes the encoded data small, but causes alignment
problems for machines that aren't aligned on these boundaries.  A
large size such as eight means the data will be aligned on virtually
every machine, but causes the encoded data to grow too big.  We chose
four as a compromise.  Four is big enough to support most
architectures efficiently, except for rare machines such as the
eight-byte aligned Cray.  Four is also small enough to keep the
encoded data restricted to a reasonable size.
.NH 2
\&Why must Variable-Length Data be Padded with Zeros?
.IX XDR "variable-length data"
.LP
It is desirable that the same data encode into the same thing on all
machines, so that encoded data can be meaningfully compared or
checksummed.  Forcing the padded bytes to be zero ensures this.
.NH 2
\&Why is there No Explicit Data-Typing?
.LP
Data-typing has a relatively high cost for what small advantages it
may have.  One cost is the expansion of data due to the inserted type
fields.  Another is the added cost of interpreting these type fields
and acting accordingly.  And most protocols already know what type
they expect, so data-typing supplies only redundant information.
However, one can still get the benefits of data-typing using XDR. One
way is to encode two things: first a string which is the XDR data
description of the encoded data, and then the encoded data itself.
Another way is to assign a value to all the types in XDR, and then
define a universal type which takes this value as its discriminant
and for each value, describes the corresponding data type.
.NH 1
\&The XDR Language Specification
.IX XDR language
.sp 1
.NH 2
\&Notational Conventions
.IX "XDR language" notation
.LP
This specification  uses an extended Backus-Naur Form  notation for
describing the XDR language.   Here is  a brief description  of the
notation:
.IP  1.
The characters
.I | ,
.I ( ,
.I ) ,
.I [ ,
.I ] ,
.I " ,
and
.I * 
are special.
.IP  2.
Terminal symbols are  strings of any  characters surrounded by
double quotes.
.IP  3.
Non-terminal symbols are strings of non-special characters.
.IP  4.
Alternative items are separated by a vertical bar ("\fI|\fP").
.IP  5.
Optional items are enclosed in brackets.
.IP  6.
Items are grouped together by enclosing them in parentheses.
.IP  7.
A
.I * 
following an item means  0 or more  occurrences of that item.
.LP
For example,  consider  the  following pattern:
.DS L
"a " "very" (", " " very")* [" cold " "and"]  " rainy " ("day" | "night")
.DE
.LP
An infinite  number of  strings match  this pattern. A few  of them
are:
.DS
"a very rainy day"
"a very, very rainy day"
"a very cold and  rainy day"
"a very, very, very cold and  rainy night"
.DE
.NH 2
\&Lexical Notes
.IP  1.
Comments begin with '/*' and terminate with '*/'.
.IP  2.
White space serves to separate items and is otherwise ignored.
.IP  3.
An identifier is a letter followed by  an optional sequence of
letters, digits or underbar ('_').  The case of identifiers is
not ignored.
.IP  4.
A  constant is  a  sequence  of  one  or  more decimal digits,
optionally preceded by a minus-sign ('-').
.NH 2
\&Syntax Information
.IX "XDR language" syntax
.DS
.ft CW
declaration:
	type-specifier identifier
	| type-specifier identifier "[" value "]"
	| type-specifier identifier "<" [ value ] ">"
	| "opaque" identifier "[" value "]"
	| "opaque" identifier "<" [ value ] ">"
	| "string" identifier "<" [ value ] ">"
	| type-specifier "*" identifier
	| "void"
.DE
.DS
.ft CW
value:
	constant
	| identifier

type-specifier:
	  [ "unsigned" ] "int"
	| [ "unsigned" ] "hyper"
	| "float"
	| "double"
	| "bool"
	| enum-type-spec
	| struct-type-spec
	| union-type-spec
	| identifier
.DE
.DS
.ft CW
enum-type-spec:
	"enum" enum-body

enum-body:
	"{"
	( identifier "=" value )
	( "," identifier "=" value )*
	"}"
.DE
.DS
.ft CW
struct-type-spec:
	"struct" struct-body

struct-body:
	"{"
	( declaration ";" )
	( declaration ";" )*
	"}"
.DE
.DS
.ft CW
union-type-spec:
	"union" union-body

union-body:
	"switch" "(" declaration ")" "{"
	( "case" value ":" declaration ";" )
	( "case" value ":" declaration ";" )*
	[ "default" ":" declaration ";" ]
	"}"

constant-def:
	"const" identifier "=" constant ";"
.DE
.DS
.ft CW
type-def:
	"typedef" declaration ";"
	| "enum" identifier enum-body ";"
	| "struct" identifier struct-body ";"
	| "union" identifier union-body ";"

definition:
	type-def
	| constant-def

specification:
	definition *
.DE
.NH 3
\&Syntax Notes
.IX "XDR language" syntax
.LP
.IP  1.
The following are keywords and cannot be used as identifiers:
"bool", "case", "const", "default", "double", "enum", "float",
"hyper", "opaque", "string", "struct", "switch", "typedef", "union",
"unsigned" and "void".
.IP  2.
Only unsigned constants may be used as size specifications for
arrays.  If an identifier is used, it must have been declared
previously as an unsigned constant in a "const" definition.
.IP  3.
Constant and type identifiers within the scope of a specification
are in the same name space and must be declared uniquely within this
scope.
.IP  4.
Similarly, variable names must  be unique within  the scope  of
struct and union declarations. Nested struct and union declarations
create new scopes.
.IP  5.
The discriminant of a union must be of a type that evaluates to
an integer. That is, "int", "unsigned int", "bool", an enumerated
type or any typedefed type that evaluates to one of these is legal.
Also, the case values must be one of the legal values of the
discriminant.  Finally, a case value may not be specified more than
once within the scope of a union declaration.
.NH 1
\&An Example of an XDR Data Description
.LP
Here is a short XDR data description of a thing called a "file",
which might be used to transfer files from one machine to another.
.ie t .DS
.el .DS L
.ft CW

const MAXUSERNAME = 32;     /*\fI max length of a user name \fP*/
const MAXFILELEN = 65535;   /*\fI max length of a file      \fP*/
const MAXNAMELEN = 255;     /*\fI max length of a file name \fP*/

.ft I
/*
 * Types of files:
 */
.ft CW

enum filekind {
	TEXT = 0,       /*\fI ascii data \fP*/
	DATA = 1,       /*\fI raw data   \fP*/
	EXEC = 2        /*\fI executable \fP*/
};

.ft I
/*
 * File information, per kind of file:
 */
.ft CW

union filetype switch (filekind kind) {
	case TEXT:
		void;                           /*\fI no extra information \fP*/
	case DATA:
		string creator<MAXNAMELEN>;     /*\fI data creator         \fP*/
	case EXEC:
		string interpretor<MAXNAMELEN>; /*\fI program interpretor  \fP*/
};

.ft I
/*
 * A complete file:
 */
.ft CW

struct file {
	string filename<MAXNAMELEN>; /*\fI name of file \fP*/
	filetype type;               /*\fI info about file \fP*/
	string owner<MAXUSERNAME>;   /*\fI owner of file   \fP*/
	opaque data<MAXFILELEN>;     /*\fI file data       \fP*/
};
.DE
.LP
Suppose now that there is  a user named  "john" who wants to  store
his lisp program "sillyprog" that contains just  the data "(quit)".
His file would be encoded as follows:
.TS
box tab (&) ;
lfI lfI lfI lfI
rfL rfL rfL l .
Offset&Hex Bytes&ASCII&Description
_
0&00 00 00 09&....&Length of filename = 9
4&73 69 6c 6c&sill&Filename characters
8&79 70 72 6f&ypro& ... and more characters ...
12&67 00 00 00&g...& ... and 3 zero-bytes of fill
16&00 00 00 02&....&Filekind is EXEC = 2
20&00 00 00 04&....&Length of interpretor = 4
24&6c 69 73 70&lisp&Interpretor characters
28&00 00 00 04&....&Length of owner = 4
32&6a 6f 68 6e&john&Owner characters
36&00 00 00 06&....&Length of file data = 6
40&28 71 75 69&(qui&File data bytes ...
44&74 29 00 00&t)..& ... and 2 zero-bytes of fill
.TE
.NH 1
\&References
.LP
[1]  Brian W. Kernighan & Dennis M. Ritchie, "The C Programming
Language", Bell Laboratories, Murray Hill, New Jersey, 1978.
.LP
[2]  Danny Cohen, "On Holy Wars and a Plea for Peace", IEEE Computer,
October 1981.
.LP
[3]  "IEEE Standard for Binary Floating-Point Arithmetic", ANSI/IEEE
Standard 754-1985, Institute of Electrical and Electronics
Engineers, August 1985.
.LP
[4]  "Courier: The Remote Procedure Call Protocol", XEROX
Corporation, XSIS 038112, December 1981.