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 desired.

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.

0
This is the server ``ok'' message. There is no additional data.

1
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:

command	response
keepall	0
if (x)	1
...
end	0

2
This is the server ``error'' message. There is no additional data. This response is given if the command produces an error.

3
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.

4
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 strings.

5
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.

6
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.

7
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.

8
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 value.

9
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.