Connection-oriented service phases

The connection-oriented service comprises three phases:

• local management

• connection setup

• data transfer

• connection shutdown

Local management

The local management defines functions between the transport user, the transport provider and other instances which control connection setup.

Examples of local functions:

• The user has to set up a communications channel to the transport provider. Each channel between the user and transport provider is called a transport endpoint. The user selects a special transport provider and sets up a transport endpoint with the t_open() function.

• Each user can manage one or more transport endpoints, which he has to identify to the transport provider. For this, the user assigns each transport endpoint a transport address, which is unique throughout the network, with the t_bind() function, i.e. he binds a transport address to the transport endpoint. The structure of the transport address is defined by the transport provider concerned.

In addition to t_open() and t_bind(), further functions exist for supporting the local transport interface management. These are summarized in following table:

Function	Description
t_alloc()	Reserves memory for the transport interface
t_bind()	Binds an address to a transport endpoint.
t_close()	Closes a transport endpoint.
t_error()	Prints an error message from the transport provider.
t_free()	Releases the memory area reserved with t_alloc().
t_getinfo()	Returns the parameter set of the current transport provider.
t_getstate()	Returns the state of the transport endpoint.
t_look()	Returns the current events of the transport endpoint.
t_open()	Sets up a transport endpoint that is to be bound to a specific transport provider.
t_optmgmt()	Negotiates protocol-specific options with the transport provider.
t_sync()	Synchronizes the transport endpoint with the transport provider.
t_unbind()	Unbinds an address from a transport endpoint.

Connection setup

In this phase, a communication connection is set up between two users.
The connection setup can be illustrated using the example of two transport users who have a client/server relationship with each other: one transport user (server) makes a number of services available to a group of users (clients) and then waits for requests from these clients. Each client can request a service after setting up a connection to the server.

The client requests a connection with the t_connect() function. One parameter of t_connect(), the address, identifies the server that the client wishes to reach. The server has to use the t_listen() function to be informed of all incoming connection requests. The server accepts a request to set up a connection with t_accept(). The transport connection is then set up.

Following table shows the connection setup functions:

Function	Description
t_accept()	Accepts a request to set up a connection.
t_connect()	Requests a connection with a particular user at a specified address.
t_listen()	Waits for a request to set up a connection from another user.
t_rcvconnect()	Confirms a connection setup request if t_connect() was called in asynchronous mode.

Data transfer

Data transfer allows two users to exchange data in both directions over an established connection. The t_snd() and t_rcv() functions send and receive data respectively over this connection. It is ensured that the data sent arrives at the receiver in the same order as sent.

Following table shows the functions for connection-oriented data transfer:

Function	Description
t_rcv()	Receives data.
t_snd()	Sends data.

Connection shutdown

The user sends the transport provider a request to shut an established connection down.There are two different types of connection shutdown:

• Abortive connection release:
  The abortive connection release directs the transport provider to terminate the connection immediately, whereby all previously sent data that has not reached the receiver may be lost. The transport user can initiate such a connection release with the t_snddis() function. The communication partner affected by this shutdown can query the cause of the shutdown with the t_rcvdis() function. The t_rcvdis() function handles incoming requests after a connection has been aborted.

• Orderly connection shutdown:
  In addition to the abortive connection release, some transport providers also enable a connection to be shut down in an orderly manner, where no data is ever lost. The t_sndrel() and t_rcvrel() functions implement an orderly connection shutdown.

  The orderly connection shutdown between two users, user1 and user2, always progresses in the following steps:

  1. User1, who is the first who wishes to shut the connection down, uses the t_sndrel() function to send user2 a request to shut the connection down. t_sndrel() informs user2 that user1 will send no further data.

  2. After receiving such a message with the t_rcvrel() function, user2 can still send data to user1.

  3. After transferring all data, user2 must also call t_sndrel(). This informs user1 that user2 is now ready to shut the connection down.

  4. The connection is shut down as soon as user1 receives the message from user2 with t_rcvrel().

Following table shows the functions for shutting a connection down:

Function	Description
t_rcvdis()	Informs about an abortive connection release.
t_rcvrel()	Indicates that the communications partner wants an orderly connection shutdown.
t_snddis()	Requests an abortive connection release or refuses a connection request.
t_sndrel()	Requests an orderly connection shutdown.

Interaction between the connection-oriented service functions

Following figure illustrates the interaction between the XTI functions which implement the separate phases of the connection-oriented service. The separate XTI functions are described in detail in section "XTI(POSIX) user functions".