Previous section.

Technical Standard: Networking Services (XNS), Issue 5.2 Draft 2.0
Copyright © 1999 The Open Group

States and Events in XTI

Transport Interface States through Connection/Release/Data Transfer States: Connection-mode are included to describe the possible states of the transport provider as seen by the transport user, to describe the incoming and outgoing events that may occur on any connection, and to identify the allowable sequence of function calls. 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 allowable sequence of functions is described in Initialisation/De-initialisation States, Data Transfer States: Connectionless-mode and Connection/Release/Data Transfer States: Connection-mode. The support functions, t_getprotaddr(), t_getstate(), t_getinfo(), t_alloc(), t_free(), t_look() and t_sync(), are excluded from the state tables because they do not affect the state of the interface. Each of these functions may be issued from any state except the uninitialised state. Similarly, the t_error(), t_strerror() and t_sysconf() functions have been excluded from the state table because they do not affect the state of the interface.

Transport Interfaces States

XTI manages a transport endpoint by using at most 8 states:

The states T_OUTREL and T_INREL are significant only if the optional orderly release function is both supported and used.

Transport Interface States describes all possible states of the transport provider as seen by the transport user. The service type may be connection-mode, connection-mode with orderly release or connectionless-mode.





State Description Service Type

T_UNINIT uninitialised - initial T_COTS
  and final state of interface T_CLTS
    T_COTS_ORD

T_UNBND unbound T_COTS
    T_COTS_ORD
    T_CLTS

T_IDLE no connection established T_COTS
    T_COTS_ORD
    T_CLTS

T_OUTCON outgoing connection pending T_COTS
  for active user T_COTS_ORD

T_INCON incoming connection pending T_COTS
  for passive user T_COTS_ORD

T_DATAXFER data transfer T_COTS
    T_COTS_ORD

T_OUTREL outgoing orderly release T_COTS_ORD
  (waiting for orderly release indication)  

T_INREL incoming orderly release T_COTS_ORD
  (waiting to send orderly release request)  



















Table: Transport Interface States

Outgoing Events

The following outgoing events correspond to the successful return or error return of the specified user-level transport functions causing XTI to change state, where these functions send a request or response to the transport provider. In Transport Interface Outgoing Events, some events (for example, accept1, accept2 and accept3) are distinguished by the context in which they occur. The context is based on the values of the following:

ocnt
Count of outstanding connection indications (connection indications passed to the user but not accepted or rejected).

fd
File descriptor of the current transport endpoint.

resfd
File descriptor of the transport endpoint where a connection will be accepted.







Event Description Service Type

opened successful return of t_open() T_COTS, T_COTS_ORD, T_CLTS

bind successful return of t_bind() T_COTS, T_COTS_ORD, T_CLTS

optmgmt successful return of t_optmgmt() T_COTS, T_COTS_ORD, T_CLTS

unbind successful return of t_unbind() T_COTS, T_COTS_ORD, T_CLTS

closed successful return of t_close() T_COTS, T_COTS_ORD, T_CLTS

connect1 successful return of t_connect() T_COTS, T_COTS_ORD
  in synchronous mode  

connect2 TNODATA error on t_connect() T_COTS, T_COTS_ORD
  in asynchronous mode, or TLOOK  
  error due to a disconnection indication  
  arriving on the transport endpoint,  
  or TSYSERR error and errno set to EINTR.  

accept1 successful return of t_accept() T_COTS, T_COTS_ORD
  with ocnt == 1, fd == resfd  

accept2 successful return of t_accept() T_COTS, T_COTS_ORD
  with ocnt == 1, fd != resfd  

accept3 successful return of t_accept() T_COTS, T_COTS_ORD
  with ocnt > 1  

snd successful return of t_snd() or t_sndv() T_COTS, T_COTS_ORD

snddis1 successful return of t_snddis() T_COTS, T_COTS_ORD
  with ocnt <= 1  

snddis2 successful return of t_snddis() T_COTS, T_COTS_ORD
  with ocnt > 1  


sndrel
successful return of t_sndrel() or t_sndreldata() T_COTS_ORD

sndudata successful return of t_sndudata() or t_sndvudata() T_CLTS



Table: Transport Interface Outgoing Events
Note:
ocnt is only meaningful for the listening transport endpoint (fd).

Incoming Events

The following incoming events correspond to the successful return of the specified user-level transport functions, where these functions retrieve data or event information from the transport provider. One incoming event is not associated directly with the return of a function on a given transport endpoint:

pass_conn
Occurs when a user transfers a connection to another transport endpoint. This event occurs on the endpoint that is being passed the connection, despite the fact that no function is issued on that endpoint. The event pass_conn is included in the state tables to describe what happens when a user accepts a connection on another transport endpoint.

In Transport Interface Incoming Events, the rcvdis events are distinguished by the context in which they occur. The context is based on the value of ocnt, which is the count of outstanding connection indications on the current transport endpoint.






Incoming    
Event Description Service Type

listen successful return of t_listen() T_COTS
    T_COTS_ORD

rcvconnect successful return of t_rcvconnect() T_COTS
    T_COTS_ORD

rcv successful return of t_rcv() or rcvv() T_COTS
    T_COTS_ORD

rcvdis1 successful return of t_rcvdis() T_COTS
  with ocnt == 0 T_COTS_ORD

rcvdis2 successful return of t_rcvdis() T_COTS
  with ocnt == 1 T_COTS_ORD

rcvdis3 successful return of t_rcvdis() T_COTS
  with ocnt > 1 T_COTS_ORD

rcvrel successful return of t_rcvrel() or rcvreldata() T_COTS_ORD

rcvudata successful return of t_rcvudata() or rcvvudata() T_CLTS

rcvuderr successful return of t_rcvuderr() T_CLTS

pass_conn receive a passed connection T_COTS
    T_COTS_ORD



Table: Transport Interface Incoming Events

Transport User Actions

Some state transitions are accompanied by a list of actions the transport user must take. These actions are represented by the notation [n], where n is the number of the specific action as described in Transport Interface User Actions.




[1] Set the count of outstanding connection indications to zero.
   
[2] Increment the count of outstanding connection indications.
   
[3] Decrement the count of outstanding connection indications.
   
[4] Pass a connection to another transport endpoint as indicated
  in t_accept().



Table: Transport Interface User Actions

State Tables

Initialisation/De-initialisation States, Data Transfer States: Connectionless-mode and Connection/Release/Data Transfer States: Connection-mode describe the possible next states, given the current state and event. The state is that of the transport provider as seen by the transport user.

The contents of each box represent the next state given the current state (column) and the current incoming or outgoing event (row). An empty box represents a state/event combination that is invalid. Along with the next state, each box may include an action list (as specified in Transport Interface User Actions). The transport user must take the specific actions in the order specified in the state table.

A separate table is shown for initialisation/de-initialisation, data transfer in connectionless-mode and connection/release/data transfer in connection-mode.






state T_UNINIT T_UNBND T_IDLE
event      

opened T_UNBND    

bind   T_IDLE [1]  

unbind     T_UNBND

closed   T_UNINIT T_UNINIT



Table: Initialisation/De-initialisation States








state T_IDLE
event  

sndudata T_IDLE

rcvudata T_IDLE

rcvuderr T_IDLE



Table: Data Transfer States: Connectionless-mode







state T_UNBND T_IDLE T_OUTCON T_INCON T_DATAXFER T_OUTREL T_INREL
event              

connect1   T_DATAXFER          

connect2   T_OUTCON          

rcvconnect     T_DATAXFER        

listen   T_INCON[2]   T_INCON[2]      

accept1       T_DATAXFER[3]      

accept2       T_IDLE[3][4]      

accept3       T_INCON[3][4]      

snd         T_DATAXFER   T_INREL

rcv         T_DATAXFER T_OUTREL  

snddis1     T_IDLE T_IDLE[3] T_IDLE T_IDLE T_IDLE

snddis2       T_INCON[3]      

rcvdis1     T_IDLE   T_IDLE T_IDLE T_IDLE

rcvdis2       T_IDLE[3]      

rcvdis3       T_INCON[3]      

sndrel         T_OUTREL   T_IDLE

rcvrel         T_INREL T_IDLE  

pass_conn T_DATAXFER T_DATAXFER          

optmgmt T_UNBND T_IDLE T_OUTCON T_INCON T_DATAXFER T_OUTREL T_INREL

closed   T_UNINIT T_UNINIT T_UNINIT T_UNINIT T_UNINIT T_UNINIT



Table: Connection/Release/Data Transfer States: Connection-mode

Events and TLOOK Error Indication

The following list describes the asynchronous events which cause an XTI call to return with a [TLOOK] error:

t_accept()
T_DISCONNECT, T_LISTEN

t_connect()
T_DISCONNECT, T_LISTEN1

t_listen()
T_DISCONNECT2

t_rcv()
T_DISCONNECT, T_ORDREL3

t_rcvconnect()
T_DISCONNECT

t_rcvrel()
T_DISCONNECT

t_rcvreldata()
T_DISCONNECT

t_rcvudata()
T_UDERR

t_rcvv()
T_DISCONNECT, T_ORDREL

t_rcvvudata()
T_UDERR

t_snd()
T_DISCONNECT, T_ORDREL

t_sndudata()
T_UDERR

t_sndv()
T_DISCONNECT, T_ORDREL

t_sndvudata()
T_UDERR

t_unbind()
T_LISTEN, T_DATA4, T_UDERR

t_sndrel()
T_DISCONNECT

t_sndreldata()
T_DISCONNECT

t_snddis()
T_DISCONNECT

Once a [TLOOK] error has been received on a transport endpoint via an XTI function, subsequent calls to that and other XTI functions, to which the same [TLOOK] error applies, will continue to return [TLOOK] until the event is consumed. An event causing the [TLOOK] error can be determined by calling t_look() and then can be consumed by calling the corresponding consuming XTI function as defined in .

Footnotes

1.
This occurs only when a t_connect is done on an endpoint which has been bound with a qlen > 0 and for which a connection indication is pending.

2.
This event indicates a disconnection on an outstanding connection indication.

3.
This occurs only when all pending data has been read.

4.
T_DATA may only occur for the connectionless mode.

Contents Next section Index