xs(7) CLIX xs(7)
NAME
xs - STREAMS XNS SPP driver
DESCRIPTION
The xs device is a STREAMS driver that provides the services of the
Sequenced Packet Protocol (SPP) to applications and other protocols on the
host machine. SPP is the connection-oriented transport layer protocol of
the Xerox Network System (XNS) Protocol suite.
The clone opens may be performed on the xs device to find the first
available free minor device.
The xs device communicates on its upper streams using the AT&T Transport
Provider Interface (TPI), providing support for the AT&T Transport Layer
Interface (TLI) to applications. The xs device provides the T_COTS_ORD
connection-oriented protocol service with orderly release (as specified by
TPI/TLI) to its upstream clients.
The xs device supports the TLI expedited data concept and maps it to the
SPP attention function. Only one-byte expedited data requests are
allowed.
The xs device supports the Transport Service Data Unit (TSDU) concept and
maps it to the SPP End Of Message (EOM) function.
The SPP header carries a one-byte field called the datastream type. The
datastream type may change from one TSDU to another TSDU, so it needs to
be sent to xs with each TLI data request. TLI makes no provisions for
such a function, so the CLIX TLI routines were modified slightly from the
AT&T standard to accommodate it. The datastream type associated with each
data request is sent to xs in the flags field of the data request. The
low-order bit of the flags field is used to indicate the T_MORE function.
The byte of datastream type to use for the data will be sent to xs in bits
8-15 of the flags field. For example, to send down no T_MORE flag and a
datastream type of 0x23, the following C code is used:
int flags;
flags = (0x23 << 8);
t_snd(fd, buf, nbytes, flags);
The datastream types 254 (0xFE) and 255 (0xFF) are used by xs to perform
the orderly release three-way handshake and should not be specified as
datastream types of normal data by applications.
The xs device does not currently support any TLI options.
The address format used in the bind and connect operations is an array of
12 characters. The network number is contained in the first four bytes of
the array, the host address is contained in the next six bytes of the
2/94 - Intergraph Corporation 1
xs(7) CLIX xs(7)
array, and the socket number is contained in the last two bytes of the
array. Each of the three numbers (network, host, and socket) is filled in
with network order (most significant byte first.) For example, to fill in
an address structure with the network address 0x000134ab, host address
08-00-36-ab-cd-03, and socket number 0x0045 use the following C code:
char addr[12];
addr[0] = 0x00;
addr[1] = 0x01;
addr[2] = 0x34;
addr[3] = 0xAB;
addr[4] = 0x08;
addr[5] = 0x00;
addr[6] = 0x36;
addr[7] = 0xAB;
addr[8] = 0xCD;
addr[9] = 0x03;
addr[10] = 0x00;
addr[11] = 0x45;
Only the socket part of the address is meaningful in bind requests,
telling xs which socket to bind. On return from a successful bind, the
entire bound address will be placed in the ret address parameter buffer.
The socket number returned may be different than the one requested if that
socket is already in use elsewhere in the system.
The maximum number of connect indications that will be queued by listening
xs streams is 5.
FILES
/dev/xs
Special device file for xs.
/usr/include/sys/xns/xns.h
XNS header file.
/usr/include/sys/xns/common.h
XNS common definitions header file.
/usr/include/sys/xns/mi.h
XNS miscellaneous header file.
NOTES
On CLIX systems, incd is usually responsible for creating the network
configuration of streams drivers/modules/multiplexors, including xs.
Manual configuration is necessary only in rare circumstances.
RELATED INFORMATION
2 Intergraph Corporation - 2/94
xs(7) CLIX xs(7)
Commands: incd(8)
Files: xr(7), xpe(7), clone(7)
2/94 - Intergraph Corporation 3