xti - General information on XTI
The X/Open Transport Interface (XTI) specification defines
an independent transport-service interface that allows
multiple users to communicate at the transport level of
the Open Systems Interconnect (OSI) reference model (other
transport providers are also supported). The specification
describes transport-layer characteristics that are
supported by a wide variety of transport-layer protocols.
Supported characteristics include: Connection establishment
State change support Event handling Data transfer
Option manipulation
Although all transport-layer protocols support these characteristics,
they vary in their level of support and their
interpretation and format. For example, there are transport-level
options that remain constant 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 Transport (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/Presentation 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,
Networking Services, Issue 4, Network Programmer's
Guide, and the reference pages for the XTI functions.
This section provides definitions of XTI-related terms and
concepts.
Transport Endpoints [Toc] [Back]
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 transport 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
functions to identify the transport endpoint. A
transport endpoint (an fd and local address) can support
only one established transport connection at a time.
To be active, a transport endpoint must have a transport
address associated with it by the t_bind function. A
transport connection is characterized by the association
of two active endpoints. This association is made by
using the functions of establishment of transport connection.
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 operation, may access
a given communication path. Note that the open function
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 [Toc] [Back]
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
transport 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 [Toc] [Back]
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 coordination 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 [Toc] [Back]
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 [Toc] [Back]
The transport service interface supports two modes of service:
connection 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 parameters and options that
govern the transfer of data. It provides and identification
mechanism that avoids the overhead of address transmission
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-oriented and supports data transfer in self-contained
units with no logical 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 presented to
the transport provider, together with the data to be
transmitted, 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 [Toc] [Back]
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 [Toc] [Back]
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 connection 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 handling 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 function 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 opening 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 appropriate
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 implementationdependent.
An event is outstanding on a transport endpoint
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 consuming 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 [Toc] [Back] Nine (eight, if orderly release is not supported) asynchronous
events are defined in the transport service
interface to cover both connection-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
The following functions contain an opt argument of the
type struct netbuf 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_sndudata
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 communication needs, for
instance by asking for high throughput or low delay. Others
allow the fine-tuning of the protocol behavior so that
communication 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 values 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.
t_optmgmt(3), xti_internet(7)
Network Programmer's Guide, X/Open CAE Specification: Networking
Services, Issue 4
xti(7)
[ Back ] |
