1 if unsuccessful.
These functions may also set
errno and t_errno.
|
|
The following TLI routines are used to access the IPX protocol:
For more information about these functions, see ``Transport Layer Interface and X/Open Transport Interface (NET)''.
The following header files must be included in the order listed in any program that uses the TLI interface to access IPX:
Except where otherwise stated, all functions return 0
if successful or 1 if unsuccessful.
These functions may also set
errno and t_errno.
The t_bind call works as specified in t_bind(NET), with the following additions:
The t_bind call allows an application to bind to a socket number, which can be either dynamic or static. ``Socket numbers'' describes procedures for obtaining both static and dynamic socket numbers.
IPX does not use the qlen field in the t_bind structure. It should be set to 0.
The t_bind call requires that a pointer to an ipxAddr_t structure be passed in the req t_bind structure (req.addr.buf field).
The t_open call works as specified in t_open(NET), with the following additions:
On input, path passes a pointer to the path of the IPX driver. The path is /dev/ipx.
On output, info receives the initialized t_info structure. The t_open function returns a file descriptor and a TLI information structure (of type t_info) when the file is opened successfully. ``Fields in a t_info structure'' describes the contents of the fields in this structure.
| Field | Value | Description |
| Addr | 12 | The 12 byte IPX address consisting of: network number (4 bytes), node number (6 bytes), and socket number (2 bytes). |
| options | 1 | IPX packet type in IPX packet header. |
| tsdu | 546 | The maximum transport service data unit is 546 bytes. |
| etsdu | -2 | Not supported. |
| connect | -2 | Not supported. |
| discon | -2 | Not supported. |
| servtype | T_CLTS | The service type is always T_CLTS (connectionless-mode service). |
The t_optmgmt call works as specified in t_optmgmt(NET), with the following additions:
The t_optmgmt function cannot be used to negotiate any of the values listed in ``Fields in a t_info structure''.
The t_optmgmt (option management) call enables the user to obtain the local IPX address. IPX does not support any negotiable options.
On input, ret passes a pointer to (or the address of) the structure that is initialized to the local IPX address.
On output, ret receives the local IPX address in the ipxAddr_t structure
IPX does not use the flags field in the t_optmgmt structure; it should be set to 0.
The len and maxlen fields in the netbuf structure must be initialized to the size of an ipxAddr_t structure. The buf field returns all the local information about this transport endpoint: source network number, source node number, and source socket number.
The req.buf and ret.buf fields must point to a structure large enough to hold an ipxAddr_t (12 bytes). Upon successful completion, ret.buf contains the source information: the first 4 bytes contain the local network number, the next 6 bytes contain the node number, and the last 2 bytes contain the local socket number. All these numbers are in high-to-low byte order.
The t_rcvudata call works as specified in t_rcvudata(NET), with the following additions:
On input, flags passes a pointer to an integer. The flag should be set to 0. Even though IPX does not use this flag, a pointer to the flag must be passed.
On output, ud receives the information in the t_unitdata structure. The ud.udata.buf field points to the data that was sent with the IPX packet.
The address (addr.buf field of the t_unitdata structure) must point to an ipxAddr_t structure.
The t_rcvudata call is the reverse of t_sndudata. The address of the sender is returned to the ud.addr field. The packet type is in the ud.opt field, and the packet data is in the ud.udata field.
The len field of opt, udata, and addr are set according to the incoming packet. The amount of data received in the IPX packet is in ud.udata.len.
There is no flow control on incoming data
because IPX is a datagram service.
If the IPX application cannot service the
incoming data as fast as the sender
generates it, the IPX driver
drops the excess incoming packets.
The t_sndudata call works as specified in t_sndudata(NET), with the following additions:
On completion,
the t_sndudata call
returns 0 if successful or 1 if unsuccessful.
Errors can also cause the error field of the
t_uderr structure to be set.
See
t_rcvuderr(NET)
for more information on
how to receive these error messages.
The address (addr.buf field of the t_unitdata structure) must point to an ipxAddr_t structure.
The destination address network number, node number, and socket number must be filled in by the user program. The numbers must be in high-to-low byte order. See ``Network byte ordering'' for more information.
The IPX user sets the packet type of the outgoing IPX packet by passing 1 byte specifying the packet type in the options (opt) field. The other fields in the outgoing IPX packet (``Checksum'', ``Length'', ``Transport control'', ``Network number'', ``Node number'', and ``Socket number'') are filled in by the IPX driver.
IPX does not support EXPEDITED data. All data is sent on a first-come, first-served basis.
A successful return by the t_sndudata call does not guarantee that the data has been sent; it guarantees only that the data has been queued up to be sent.
Because the largest number of bytes that can be sent with any t_sndudata is 546, any attempt to send more than 546 bytes results in an error.
If ud.udata.len equals 0, no packet is sent.
The t_unbind call works as specified in t_unbind(NET), with the following additions:
This call releases the IPX socket number used by this transport endpoint for future use. The t_close function calls t_unbind.
This call places the transport endpoint in a T_UNBND state,
allowing the process to bind to a new socket number.