The X/Open Transport Interface (XTI) 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, [1] 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.
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 (TCP), Xerox Network Systems (XNS), Systems Network Architecture (SNA), X.25, Asynchronous Transfer Mode (ATM) or any other transport layer provider that function at Layer 4 of the OSI Model. [2]
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. [3] It is based on the UNIX System V Transport Layer Interface (TLI)., [4] which is a transport service definition adhering to the Open Systems Interconnection (OSI) model. [5] XTI consists of a cooperating STREAMS module, link library application programming interface (API), header files, and the rules and restrictions elaborating how XTI processes work and interact. [3]
XTI is protocol independent. However, applications still need to be aware of the desired transport system in order to select it. [6] Applications can achieve this transport protocol independence using the Network Selection Facilities also provided by the XTI/TLI library (libnsl). [7]
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. Both, the TLI and BSD sockets interfaces in UNIX SVR 3 [8] and SVR 4 [9] 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(SO_ERROR) 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 (e.g. sendmsg from unbound state on connectionless socket, connect from unbound state on connection-oriented socket); whereas XTI API functions can only be issued from a specific and corresponding state (e.g. t_bind may only be issued from the unbound state, t_connect only from the bound state).
Real-time XTI end user 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. XTI asynchronous mode permits end user application be notified about various events of file handles: connections indications requests, new data, time outs.
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_strerror() and t_getprotaddr().
The XTI library is found in UNIX System V but also has ports for other systems, such as OpenSS7 for Linux.
The Open Systems Interconnection model is a conceptual model that 'provides a common basis for the coordination of [ISO] standards development for the purpose of systems interconnection'. In the OSI reference model, the communications between a computing system are split into seven different abstraction layers: Physical, Data Link, Network, Transport, Session, Presentation, and Application.
The Portable Operating System Interface is a family of standards specified by the IEEE Computer Society for maintaining compatibility between operating systems. POSIX defines both the system and user-level application programming interfaces (APIs), along with command line shells and utility interfaces, for software compatibility (portability) with variants of Unix and other operating systems. POSIX is also a trademark of the IEEE. POSIX is intended to be used by both application and system developers.
The Single UNIX Specification (SUS) is a standard for computer operating systems, compliance with which is required to qualify for using the "UNIX" trademark. The standard specifies programming interfaces for the C language, a command-line shell, and user commands. The core specifications of the SUS known as Base Specifications are developed and maintained by the Austin Group, which is a joint working group of IEEE, ISO/IEC JTC 1/SC 22/WG 15 and The Open Group. If an operating system is submitted to The Open Group for certification, and passes conformance tests, then it is deemed to be compliant with a UNIX standard such as UNIX 98 or UNIX 03.
Xerox Network Systems (XNS) is a computer networking protocol suite developed by Xerox within the Xerox Network Systems Architecture. It provided general purpose network communications, internetwork routing and packet delivery, and higher level functions such as a reliable stream, and remote procedure calls. XNS predated and influenced the development of the Open Systems Interconnection (OSI) networking model, and was very influential in local area networking designs during the 1980s.
Berkeley sockets is an application programming interface (API) for Internet sockets and Unix domain sockets, used for inter-process communication (IPC). It is commonly implemented as a library of linkable modules. It originated with the 4.2BSD Unix operating system, which was released in 1983.
In computer networking, the transport layer is a conceptual division of methods in the layered architecture of protocols in the network stack in the Internet protocol suite and the OSI model. The protocols of this layer provide end-to-end communication services for applications. It provides services such as connection-oriented communication, reliability, flow control, and multiplexing.
An application layer is an abstraction layer that specifies the shared communications protocols and interface methods used by hosts in a communications network. An application layer abstraction is specified in both the Internet Protocol Suite (TCP/IP) and the OSI model. Although both models use the same term for their respective highest-level layer, the detailed definitions and purposes are different.
In computing, the Windows Sockets API (WSA), later shortened to Winsock, is an application programming interface (API) that defines how Windows network application software should access network services, especially TCP/IP. It defines a standard interface between a Windows TCP/IP client application and the underlying TCP/IP protocol stack. The nomenclature is based on the Berkeley sockets API used in BSD for communications between programs.
In computer science, message queues and mailboxes are software-engineering components typically used for inter-process communication (IPC), or for inter-thread communication within the same process. They use a queue for messaging – the passing of control or of content. Group communication systems provide similar kinds of functionality.
Message-oriented middleware (MOM) is software or hardware infrastructure supporting sending and receiving messages between distributed systems. MOM allows application modules to be distributed over heterogeneous platforms and reduces the complexity of developing applications that span multiple operating systems and network protocols. The middleware creates a distributed communications layer that insulates the application developer from the details of the various operating systems and network interfaces. APIs that extend across diverse platforms and networks are typically provided by MOM.
William Richard (Rich) Stevens was a Northern Rhodesia-born American author of computer science books, in particular books on UNIX and TCP/IP.
X/Open group was a consortium founded by several European UNIX systems manufacturers in 1984 to identify and promote open standards in the field of information technology. More specifically, the original aim was to define a single specification for operating systems derived from UNIX, to increase the interoperability of applications and reduce the cost of porting software. Its original members were Bull, ICL, Siemens, Olivetti, and Nixdorf—a group sometimes referred to as BISON. Philips and Ericsson joined in 1985, at which point the name X/Open was adopted.
In computer networking, the Transport Layer Interface (TLI) was the networking API provided by AT&T UNIX System V Release 3 (SVR3) in 1987 and continued into Release 4 (SVR4). TLI was the System V counterpart to the BSD sockets programming interface, which was also provided in UNIX System V Release 4 (SVR4). TLI was later standardized as XTI, the X/Open Transport Interface.
Twisted is an event-driven network programming framework written in Python and licensed under the MIT License.
In computer networking, STREAMS is the native framework in Unix System V for implementing character device drivers, network protocols, and inter-process communication. In this framework, a stream is a chain of coroutines that pass messages between a program and a device driver. STREAMS originated in Version 8 Research Unix, as Streams.
Computer network programming involves writing computer programs that enable processes to communicate with each other across a computer network.
A network socket is a software structure within a network node of a computer network that serves as an endpoint for sending and receiving data across the network. The structure and properties of a socket are defined by an application programming interface (API) for the networking architecture. Sockets are created only during the lifetime of a process of an application running in the node.
A Unix domain socket aka UDS or IPC socket is a data communications endpoint for exchanging data between processes executing on the same host operating system. It is also referred to by its address family AF_UNIX
. Valid socket types in the UNIX domain are:
Unix Network Programming is a book written by W. Richard Stevens. It was published in 1990 by Prentice Hall and covers many topics regarding UNIX networking and Computer network programming. The book focuses on the design and development of network software under UNIX. The book provides descriptions of how and why a given solution works and includes 15,000 lines of C code. The book's summary describes it as "for programmers seeking an in depth tutorial on sockets, transport level interface (TLI), interprocess communications (IPC) facilities under System V and BSD UNIX." The book has been translated into several languages, including Chinese, Italian, German, Japanese and others.