Up: Server Mode
Previous: Server Mode
The Response Message Format
Numeric data are sent in ``network byte order'' which means that the
MSB arrives first. Integers are always 32-bits, other numeric data
are 64-bit IEEE floating point values. The raw bytes read for a
numeric value must be converted to the machine's byte order before
being processed in a program. For integers, the ntohl C library
function is usually available. For floating values, an example
conversion function is provided in the xclient.cc file. The
byte order is the same as that used by Sun sparc systems, thus this
issue can be ignored on those systems, unless code portability is
All response messages begin with a 4-byte integer, which may
constitute the entire message in some circumstances. This (and all
numeric values) is in network byte order, so must be converted to host
byte order before processing. The first integer is the ``response
code'' possibly ORed with the ``longform'' flag. The response code is
an integer 0-9, and the longform flag is hex value 80.
If the longform flag is not set, then no more data exists in the
message. Otherwise, most response codes will be followed by
additional data. The possible responses are described below.
This is the server ``ok'' message. There is no additional data.
This is the server ``more'' message. There is no additional data.
This response is given when the server is waiting for input required
to complete a script conditional block, for example:
This is the server ``error'' message. There is no additional data.
This response is given if the command produces an error.
This is the server ``scalar'' message. If the longform flag is set,
there are 8 bytes of following data, representing a
double-precision IEEE floating-point value.
This is the server ``string'' message. If the longform flag is set,
a 4-byte size integer follows, in turn followed by the string
characters. The size value is the number of characters in the
string and includes the null termination character of ASCII
This is the server ``array'' message. If the longform flag is set,
a 4-byte integer follows, giving the number of elements in the
array. This is followed by the array data, 8 bytes per element,
in IEEE double-precision floating-point form.
This is the server ``zlist'' message. If the longform flag is set, a
4-byte integer follows, which gives the number of trapezoids in the
list. This is followed by the trapezoid list data, with 24 bytes per
trapezoid (six 4-byte integers each). The values are coordinates in
the internal units (usually 1000 units per micron), in the order xll, xlr, yl, xul, xur, yu.
This is the server ``lexpr'' message, which is the return for the
layer expression type. This is treated as a string. If the longform
flag is set, a 4-byte size integer follows, followed by the text of
the layer expression. The size includes the null termination
character of the string.
This is the server ``handle'' message, which is the return for all
handle types. This is basically useless on the local machine, since
the underlying data resides on the server. If the longform flag is
set, a 4-byte integer follows, which gives the handle identification
This is the server geometry stream message. This message always
returns data, the longform flag is ignored. The type 9 return is
unique to the geometry stream response from the geom command.
The ASCII string responses from the geom command use type 4 in
the normal way, though they are always in ``longform''. The type 9
record is very similar to a string, however the first 8 bytes of the
string contains two integers: the first integer is the compressed
size of the following data, and the second integer is the uncompressed
size. The compressed size can be zero, in which case compression is
not used. The actual string length is the compressed size if nonzero,
otherwise the uncompressed size. The string contains OASIS geometry
records, as in a CBLOCK if compressed.
The user will have to supply an OASIS reader to interpret the stream.
Xic provides script functions for this purpose.
Up: Server Mode
Previous: Server Mode
Stephen R. Whiteley