*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->Tru64 Unix man pages -> xti (7)              



NAME    [Toc]    [Back]

       xti - General information on XTI

DESCRIPTION    [Toc]    [Back]

       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    [Toc]    [Back]

       This section provides definitions of XTI-related terms and

   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

       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

       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

       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

       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

       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.


       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:

       XTI manages a transport endpoint by  using  the  following
       states:   T_UNINIT   T_UNBND   T_IDLE   T_OUTCON   T_INCON

       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    [Toc]    [Back]

       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    [Toc]    [Back]

       t_optmgmt(3), xti_internet(7)

       Network Programmer's Guide, X/Open CAE Specification: Networking
 Services, Issue 4

[ Back ]
 Similar pages
Name OS Title
strqset Tru64 General: Changes information about a queue
strqget Tru64 General: Obtains information about a queue
intro HP-UX introduction to HP-UX general information section
task Tru64 General: Contains task-specific information
slock Tru64 General: Contains simple lock-specific information
thread Tru64 General: Contains kernel threads-related information
lock Tru64 General: Contains complex lock-specific information
rsvp Tru64 Resource ReSerVation Protocol general information
get_info Tru64 General: Returns system-specific information
RSVP Tru64 Resource ReSerVation Protocol general information
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service