X/Open Transport Interface
The X/Open Transport Interface is an Open Group specification for network application programming present in UNIX System V operating systems. It provides OSI transport layer services with protocol independence. Although Open Group considers this specification withdrawn, an implementation is part of the standard programming interfaces on modern UNIX System V operating systems where it is implemented using the STREAMS character input/output mechanism.
Overview
The X/Open Transport Interface is a specification that defines an independent transport-service interface for network applications. Programs using XTI can be run over a variety of transport providers, such as the Transmission Control Protocol, Xerox Network Systems, Systems Network Architecture, X.25, Asynchronous Transfer Mode or any other transport layer provider that function at Layer 4 of the OSI Model.XTI provides similar functionality as the Berkeley sockets interface, however it is protocol independent in contrast to the socket interface which is heavily biased toward the Internet Protocols. It is based on the UNIX System V Transport Layer Interface., which is a transport service definition adhering to the Open Systems Interconnection model.
XTI consists of a cooperating STREAMS module, link library application programming interface, header files, and the rules and restrictions elaborating how XTI processes work and interact.
Protocol independence
XTI is protocol independent. However, applications still need to be aware of the desired transport system in order to select it. Applications can achieve this transport protocol independence using the Network Selection Facilities also provided by the XTI/TLI library.Sockets-to-XTI/TLI equivalents
Although XTI/TLI is similar to the BSD socket interface, neither is included or includes the other one and severalfunctions having the same role have different behavior. Both, the TLI and BSD sockets interfaces in UNIX SVR 3 and SVR 4 operating systems releases are implemented using the same underlying STREAMS Transport Service Interface.
The following table shows approximate equivalence between the POSIX XTI and sockets interfaces:
| XTI/TLI Interface | Socket Interface | Same Semantics |
| t_open | socket | yes, except t_open can perform t_getinfo on open. |
| - | socketpair | - |
| t_getinfo | - | - |
| t_getprotaddr | getsockname, getpeername | yes, but t_getprotaddr can perform both calls in one. |
| t_bind | bind, listen | yes, except t_bind can bind and listen in a single operation. |
| t_optmgmt | getsockopt, setsockopt | yes, except t_optmgmt can obtain default values and negotiate values; getsockopt and setsockopt can only set and retrieve current values. |
| t_unbind | bind | yes, binding to AF_UNSPEC unbinds a socket. |
| t_close | close | yes, except for connected endpoints t_close always results in abortive disconnect, whereas close sometimes results in orderly release. |
| t_getstate | - | - |
| t_sync | - | - |
| t_alloc | - | - |
| t_free | - | - |
| t_look | select, getsockopt | select and getsockopt cannot provide all of the indications provided by t_look. |
| t_error | perror | yes, except XTI uses t_errno in addition to errno and can indicate both transport errors and UNIX system errors. |
| t_strerror | strerror | yes |
| t_connect | connect | t_bind is needed before t_connect |
| t_rcvconnect | select | t_rcvconnect is equivalent to a select on a socket set O_NONBLOCK upon which a connect was issued. |
| t_listen, t_accept, t_snddis | accept | accept cannot refuse a connection, whereas a connection received with t_listen can subsequently be accepted with t_accept, or refused with t_snddis. |
| t_snd, t_sndv | send, sendto, sendmsg | yes, but t_snd and t_sndv can only be used for connection-mode transport. |
| t_rcv, t_rcvv | recv, recvfrom, recvmsg | yes, but t_rcv and t_rcvv can only be used for connection-mode transport. |
| t_snddis | close, shutdown | After issuing t_snddis a program can continue to listen for requests or reestablish connection with t_connect function, while close frees the socket file descriptor. To continue communication a new connection needs to be established by issuing again socket and bind, listen or connect. |
| t_rcvdis | ENOTCONN, ECONNRESET, EPIPE, SIGPIPE | yes, except sockets receives the disconnect as an error or signal. |
| t_sndrel, t_sndreldata | shutdown | yes, but shutdown is not capable of sending data with the orderly release: t_sndreldata can send data with orderly release. T_sndrel only shuts down the sending direction. |
| t_rcvrel, t_rcvreldata | - | - |
| t_sndudata, t_sndvudata | sendmsg | yes, but t_sndudata and t_sndvudata can only be used portably for connectionless-mode data. |
| t_rcvudata, t_rcvvudata | recvmsg | yes, but t_rcvudata and t_rcvvudata can only be used portably for connectionless-mode data. |
| t_rcvuderr | - | - |
| read, write | read, write | XTI/TLI needs to push tirdwr module before calling read/write functions |
To ascertain the proper sequence of library function calls, XTI/TLI uses state indicators, in a similar manner to the sockets API. However, some socket API functions can be called from multiple states ; whereas XTI API functions can only be issued from a specific and corresponding state.