xti(7)xti(7)NAMExti - General information on XTI
DESCRIPTION
The X/Open Transport Interface (XTI) specification defines an indepen‐
dent transport-service interface that allows multiple users to communi‐
cate at the transport level of the Open Systems Interconnect (OSI) ref‐
erence model (other transport providers are also supported). The spec‐
ification describes transport-layer characteristics that are supported
by a wide variety of transport-layer protocols. Supported characteris‐
tics include: Connection establishment State change support Event han‐
dling Data transfer Option manipulation
Although all transport-layer protocols support these characteristics,
they vary in their level of support and their interpretation and for‐
mat. For example, there are transport-level options that remain con‐
stant across all transport providers while there are other options that
are transport-provider specific or have different values or names for
different transport providers.
While XTI gives transport users considerable independence from the
underlying transport provider, the differences between providers are
not entirely hidden. You can write transport-provider-independent
software primarily by using only functions supported by all providers,
avoiding option management, and using a provider-independent means of
acquiring addresses.
Transport providers can be divided into the following categories: Those
corresponding to traditional transport providers, such as: ISO Trans‐
port (connection-oriented or connectionless) TCP UDP NetBIOS
For more information on TCP and UDP, see the xti_internet(7)
reference page. Those corresponding to commonly used subsets of
higher-layer protocols that provide transport-like services,
such as: Minimal fuctionality OSI (mOSI), that is, OSI ACSE/Pre‐
sentation with the kernel and duplex functional units SNA LU6.2
subset Mixed-protocol providers that provide the appearance of
one protocol over a different protocol, such as: ISO transport
appearance (connection-oriented) over TCP
For more information on XTI, see the X/Open CAE Specification, Network‐
ing Services, Issue 4, Network Programmer's Guide, and the reference
pages for the XTI functions.
DEFINITIONS
This section provides definitions of XTI-related terms and concepts.
Transport Endpoints
A transport endpoint specifies a communication path between a transport
user and a specific transport provider, which is identified by a local
file descriptor (fd). When you open a transport provider identifier, a
local fd is returned which identifies the transport endpoint. A trans‐
port provider is defined to be the transport protocol that provides the
services of the transport layer. All requests to the transport
provider must pass through a transport endpoint. The fd is returned by
the function t_open and is used as an argument to the subsequent func‐
tions to identify the transport endpoint. A transport endpoint (an fd
and local address) can support only one established transport connec‐
tion at a time.
To be active, a transport endpoint must have a transport address asso‐
ciated with it by the t_bind function. A transport connection is char‐
acterized by the association of two active endpoints. This association
is made by using the functions of establishment of transport connec‐
tion. The fd is a communication path to a transport provider. There
is no direct assignation of the processes to the transport provider, so
multiple processes, which obtain the fd by open, fork, or dup opera‐
tion, may access a given communication path. Note that the open func‐
tion works only if the opened character string is a pathname.
Note that, to guarantee portability, the only operations that the
applications can perform on any fd returned by t_open are those defined
by XTI and fcntl, dup, or dup2. Any other operations will have system-
dependent results.
Transport Providers
The transport layer may comprise one of more transport providers at the
same time. The identifier parameter of the transport provider passed
to the t_open function determines the required transport provider. To
keep the applications portable, the identifier parameter of the trans‐
port provider should not be hard-coded into the application source
code.
An application that wants to manage multiple transport providers must
call t_open for each provider. For example, a server application that
is waiting for incoming connect indications from several transport
providers must open a transport endpoint for each provider and listen
for connect indications on each of the associated fds.
Association of a UNIX Process to an Endpoint
One process can simultaneously open several file descriptors. However,
in synchronous mode, the process must manage the different actions of
the associated transport connections sequentially. Conversely, several
processes can share the same fd (by fork or dup operations) but they
have to synchronize themselves to avoid issuing a function that is
unsuitable to the current state of the transport endpoint.
It is important to remember that the transport provider treats all
users of a transport endpoint as a single user. If multiple processes
are using the same endpoint, they should coordinate their activities so
as not to violate the state of the provider. The t_sync function
returns the current state of the provider to the user, thereby enabling
the user to verify the state before taking further action. This coor‐
dination is only valid among cooperating processes; it is possible that
a process or an incoming event could change the provider's state after
a t_sync is issued.
A process can listen for an incoming connect indication on one fd and
accept the connection on a different fd which has been bound with the
qlen parameter (see t_bind) set to zero. This facilitates the writing
of a listener application whereby the listener waits for all incoming
connect indications on a given Transport Service Access Point (TSAP).
The listener accepts the connection on a new fd and forks a child
process to service the request without blocking other incoming connect
indications.
Use of the Same Protocol Address
If several endpoints are bound to the same protocol address, only one
at a time can be listening for incoming connections. However, others
can be in data transfer state or establish a transport connection as
initiators.
Modes of Service
The transport service interface supports two modes of service: connec‐
tion mode and connectionless mode. A single transport endpoint cannot
support both modes of services simultaneously.
The connection-mode transport service is circuit-oriented and enable
data to be transferred over an established connection in a reliable,
sequenced manner. This service enables the negotiation of the parame‐
ters and options that govern the transfer of data. It provides and
identification mechanism that avoids the overhead of address transmis‐
sion and resolution during the data transfer phase. It also provides a
context in which successive units of data, transferred between peer
users, are logically related. This service facilitates applications
that require relatively long-lived, data stream-oriented interactions.
In contrast, the connectionless-mode transport service is message-ori‐
ented and supports data transfer in self-contained units with no logi‐
cal relationship required among multiple units. These units are also
known as datagrams. This service requires a preexisting association
between the peer users involved, which determines the characteristics
of the data to be transmitted. No dynamic negotiation of parameters
and options is supported by this service. All the information required
to deliver a unit of data (for example, destination address) is pre‐
sented to the transport provider, together with the data to be trans‐
mitted, in a single service access which need not relate to any other
service access. Also, each unit of data transmitted is entirely self-
contained, and can be independently routed by the transport provider.
This service is attractive to application that involve short-term
request and response interactions, exhibit a high level of redundancy,
are dynamically reconfigurable, or do not require guaranteed, in-
sequence delivery of data.
Error Handling
Two levels of error are defined for the transport interface. The first
is the library error level. Each library function has one or more
error returns. Failures are indicated by a return value of -1. An
external integer, t_errno, which is defined in the header file <xti.h>,
holds the specific error number when such a failure occurs. This value
is set when errors occur but it is not cleared on successful library
calls, so it should be tested only after an error has been indicated.
A diagnostic function, t_error, prints out information on the current
transport error. The state of the transport provider may change if a
transport error occurs.
The second level of error is the operating system service routine
lever. A special library level error number has been defined called
TSYSERR which is generated by each library function when an operating
system service routine fails or some general error occurs. When a
function sets t_errno to TSYSERR, the specific system error may be
accessed through the external variable errno.
For example, a system error can be generate by the transport provider
when a protocol error has occurred. If the error is severe, it may
cause the file descriptor and transport endpoint to be unusable. To
continue in this case, all users of the fd must close it. Then the
transport endpoint may be reopened and initialized.
Synchronous and Asynchronous Execution Modes
The transport service interface is inherently asynchronous; various
events can occur that are independent of the actions of a transport
user. For example, a user may be sending data over a transport connec‐
tion when an asynchronous disconnect indication arrives. The user must
be informed that the connection has been broken.
The transport service interface supports two execution modes for han‐
dling asynchronous events: synchronous mode and asynchronous mode. In
the synchronous mode of operation, the transport primitives wait for
specific events before returning control to the user. While waiting,
the user cannot perform other tasks. For example, a function that
attempts to receive data in synchronous mode waits until data arrives
before returning control to the user. Synchronous mode is the default
mode of execution. It is useful for user processes that maintain only
a single transport connection. Note that if a signal arrives, blocking
calls are interrupted and return a negative return code with t_errno
set to TSYSERR and errno set to EINTR. In this case the call will have
no effect.
The asynchronous mode of operation provides a mechanism for notifying a
user of some event without forcing the user to wait for the event. The
handling of networking events in an asynchronous manner is a desirable
capability of the transport interface. This enables users to perform
useful work while waiting for a particular event. For example, a func‐
tion that attempts to receive data in asynchronous mode immediately
returns control to the user if no data is available. The user can then
periodically poll for incoming data until it arrives. The asynchronous
mode is intended for those applications that expect long delays between
events and have other tasks that they can perform in the meantime or
handle multiple connections concurrently.
The two execution modes are not provided through separate interfaces or
different functions. Instead, functions that process incoming events
have two modes of operation: synchronous and asynchronous. The desired
mode is specified through the O_NONBLOCK flag, which can be set when
the transport provider is initially opened, or at any time after open‐
ing using the fcntl operating system service routine. The effect of
this flag is local to this process and is completely specified in the
description of each function.
A process that issues functions in synchronous mode must still be able
to recognize certain asynchronous events and act on them, if necessary.
This is handled through a special transport error, TLOOK, which is
returned by a function when an asynchronous event occurs. The t_look
function is then invoked to identify the specific event that has
occurred when this error is returned.
Another means to notify a process that an asynchronous event has
occurred is polling. The polling capability enables processes to do
useful work and periodically poll for one of the above asynchronous
events. This facility is provided by setting O_NONBLOCK for the appro‐
priate primitives.
All events that occur at a transport endpoint are stored by XTI. These
events are retrievable one at a time using the t_look function. If
multiple events occur, the order in which t_look returns the events is
implementation-dependent. An event is outstanding on a transport end‐
point until it is consumed. Every event has a corresponding consuming
function that handles the event and clears it. For example, both
T_DATA and T_EXDATA events are consumed when the corresponding consum‐
ing function has read all the corresponding data associated with that
event. The intention is that T_DATA should always indicate that there
is data to receive. Two events, T_GODATA and T_GOEXDATA, are also
cleared as they are returned by t_look. For more information, see the
Network Programmer's Guide.
EVENTS AND STATES IN XTI
Nine (eight, if orderly release is not supported) asynchronous events
are defined in the transport service interface to cover both connec‐
tion-mode and connectionless-mode service. They are represented as
separate bits in a bit-mask using the following defined symbolic names:
T_LISTEN T_CONNECT T_DATA T_EXDATA T_DISCONNECT T_ORDREL T_UDERR
T_GODATA T_GOEXDATA
XTI manages a transport endpoint by using the following states:
T_UNINIT T_UNBND T_IDLE T_OUTCON T_INCON T_DATAXFER T_INREL T_OUTREL
The T_OUTREL and T_INREL states are significant only if the optional
orderly release function is both supported and used. These are
described in more detail in the Network Programmer's Guide.
Given a current state and event, the transition to the next state is
shown, as well as any actions that must be taken by the transport user.
The following support function can be issued from any state except the
uninitialized state: t_getprotaddr t_getstate t_getinfo t_alloc t_free
t_look t_sync
XTI OPTIONS
The following functions contain an opt argument of the type struct net‐
buf as an input or output parameter. This argument is used to convey
options between the transport user and the transport provider: t_accept
t_connect t_listen t_optmgmt t_rcvconnect t_rcvudata t_rcvuderr t_sndu‐
data
There is no general definition about the possible contents of options.
There are general XTI options and those that are specific for each
transport provider. Some options allow the user to tailor his communi‐
cation needs, for instance by asking for high throughput or low delay.
Others allow the fine-tuning of the protocol behavior so that communi‐
cation with unusual characteristics can be handled more effectively.
Other options are for debugging purposes.
All options have default values. Their values have meaning to and are
defined by the protocol level in which they apply. However, their val‐
ues can be negotiated by a transport user. This includes the simple
case where the transport user can simply enforce its use. Often, the
transport provider or even the remote transport user can have the right
to negotiate a value of lesser quality than the proposed one, that is,
a delay can become longer, or a throughput may become lower.
For more information on using XTI options, see the Network Programmer's
Guide.
SEE ALSOt_optmgmt(3), xti_internet(7)
Network Programmer's Guide, X/Open CAE Specification: Networking Ser‐
vices, Issue 4
xti(7)
