 |
Index for
Section 7 |
|
 |
Alphabetical
listing for X |
|
 |
Bottom of
page |
|
xti(7)
NAME
xti - General information on XTI
DESCRIPTION
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.
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 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
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
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
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: 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
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 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
implementation-dependent. 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
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
XTI OPTIONS
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.
SEE ALSO
t_optmgmt(3), xti_internet(7)
Network Programmer's Guide, X/Open CAE Specification: Networking Services,
Issue 4
|
Index for
Section 7 |
|
|
Alphabetical
listing for X |
|
 |
Top of
page |
|