X/Open Transport Interface
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
No issues specified. Please specify issues, or remove this template. |
X/Open Transport Interface
The X/Open Transport Interface is both an Open Group specification and a network programming interface present in UNIX System V. It provides ISO transport layer services with arguable protocol independence. Although Open Group states this specification as obsolete[1], it's implementation is part of the standard programming interfaces on modern UNIX System V operating systems where it's implemented using STREAMS.
What is XTI?
The X/Open Transport Interface (XTI) is a specification that defines an independent transport-service interface. Programs written to XTI can be run over a variety of transport providers, such as the Transmission Control Protocol (TCP), Xerox Network Systems(XNS), Systems Network Architecture(SNA) or any other transport layer provider that function at layer 4 of the OSI Model.
XTI implementation is a network programming interface is similar to the most widely known Berkeley sockets interface and is based on the AT&T Transport Layer Interface (TLI). TLI, in turn, is based on the transport service definition for the Open Systems Interconnection (OSI) model. XTI consists of library calls, header files, and the rules and restrictions elaborating how XTI processes work and interact.
Protocol Independence
Although designed to be protocol independent, application still needs to be aware of desired transport in order to select it. This is why XTI is not agreed to be a transport layer transparent access mode[2].
XTI/TLI versus Sockets Interfaces
The main differences between XTI/TLI and sockets interfaces are related to transport independence:
- Privileged ports – The notion of privileged ports is not supported in the transport-independent environment. These ports are not portable as they are a convention of BSD sockets implementation.
- Opaque addresses – Separating the portion of an address that names a host from the portion of an address that names the service at that host cannot be done in a transport-independent fashion.
- Broadcast – No transport-independent form of broadcast address exists.
Also transport options are usually tied to a specific transport but need not to be so.
Sockets-to-XTI/TLI Equivalents
Although XTI/TLI is similar to the BSD socket interface neither is included or includes the other one and several functions having the same role have different behavior. The following table shown approximative equivalence between the two interfaces:
| XTI/TLI interface | Socket interface | Same Semantic |
|---|---|---|
| t_open | socket | yes |
| - | socketpair | - |
| t_bind | bind | t_bind can bind one protocol address to more than one transport end point; Also t_bind sets the queue depth while for sockets this is done in listen call |
| t_getinfo t_optmgmt | getsockopt getsockopt setsockopt | no, t_getinfo/t_optmgmt gets/sets only transport layer options |
| t_unbind | - | - |
| t_close | close | yes |
| t_getstate | - | - |
| t_sync | - | - |
| t_alloc | - | - |
| t_free | - | - |
| t_look | - | the same as getsockopt with SO_ERROR |
| t_error | perror | yes |
| t_connect | connect | t_bind is needed before t_connect |
| t_rcvconnect | - | - |
| t_listen | listen | listen will set the queue depth |
| t_accept | accept | t_accept doesn't block because it is issued after connection indication is received. accept, on the other hand is issued in anticipation of a connect request and therefore may block until the connect request occurs. |
| t_snd | send sendto sendmsg | yes |
| t_rcv | recv recvfrom recvmsg | yes |
| t_snddis | shutdown | after issuing t_snddis a program can continue to listen for requests or reestablish connection with t_connect function, while shutdown frees system allocated resources. To continue communication a new connection needs to be established - issue again socket and bind |
| t_rcvdis | - | - |
| t_sndrel | - | - |
| t_rcvrel | - | - |
| t_sndudata | sendto | yes |
| t_rcvudata | recvmsg | yes |
| t_rcvuderr | - | - |
| read, write | read, write | XTI/TLI needs to push tirdwr module before calling read/write functions |
In order to control the proper sequence of calls, both XTI/TLI and sockets interface use states indicators but interfaces being slightly different also states are different. XTI/TLI states are mutual exclusive but socket's states are not.
XTI/TLI Asynchronous Mode
Real-time XTI consummer application will use XTI interface asynchronously(otherwise there are no guarantees about how long a call waiting for data will block). The set of functions is the same as synchronous calls but when initializing transport endpoint, O_NONBLOCK parameter is provided(or later with fcntl). XTI asynchronous mode permits consummer application be notified about various events of file handles: connections indications requests, new data, time outs.
XTI refines TLI
XTI refines TLI providing additional error messages, additional events to manage flow control and simplifies functions parameters(XTI always opens transport endpoints as read-write). Also, XTI checks the value of qlen to prevent blocking indefinitely when application issue t_listen. Additional utility functions have been added: t_strerr and t_getprotaddr().
Implementations
XTI library is found in UNIX System V but also has ports for other systems: Linux - OpenSS7
References
- Programming Interfaces Guide - Sun Microsystems, Inc. September 2008