Connection mode is circuit oriented. Data are transmitted in sequence over an established connection. The mode also provides an identification procedure that avoids address resolution and transmission in the data transfer phase. Use this service for applications that require data stream-oriented interactions. Connection mode transport service has four phases:
Local management
Connection establishment
Data transfer
Connection release
The local management phase defines local operations between a transport user and a transport provide as shown in Figure 3-2. For example, a user must establish a channel of communication with the transport provider. Each channel between a transport user and transport provider is a unique endpoint of communication, and is called the transport endpoint. t_open() lets a user choose a particular transport provider to supply the connection mode services, and establishes the transport endpoint.
Each user must establish an identity with the transport provider. A transport address is associated with each transport endpoint. One user process can manage several transport endpoints. In connection mode service, one user requests a connection to another user by specifying the other's address. The structure of a transport address is defined by the transport provider. An address can be as simple as an unstructured character string (for example, file_server), or as complex as an encoded bit pattern that specifies all information needed to route data through a network. Each transport provider defines its own mechanism for identifying users. Addresses can be assigned to the endpoint of a transport by t_bind().
In addition to t_open() and t_bind(), several routines support local operations. Table 3-2 summarizes all local management routines of XTI/TLI.
Table 3-2 Routines of XTI/TLI for Operating on the Endpoint
Command |
Description |
---|---|
Allocates XTI/TLI data structures |
|
t_bind |
Binds a transport address to a transport endpoint |
Closes a transport endpoint |
|
Prints a XTI/TLI error message |
|
Frees structures allocated using t_alloc |
|
Returns a set of parameters associated with a particular transport provider |
|
Returns the local and/or remote address associated with endpoint (XTI only) |
|
Returns the state of a transport endpoint |
|
Returns the current event on a transport endpoint |
|
Establishes a transport endpoint connected to a chosen transport provider |
|
Negotiates protocol-specific options with the transport provider |
|
Synchronizes a transport endpoint with the transport provider |
|
Unbinds a transport address from a transport endpoint |
The connection phase lets two users create a connection, or virtual circuit, between them, as shown in Figure 3-3.
For example, the connection phase occurs when a server advertises its service to a group of clients, then blocks on t_listen() to wait for a request. A client tries to connect to the server at the advertised address by a call to t_connect(). The connection request causes t_listen() to return to the server, which can call t_accept() to complete the connection.
Table 3-3 summarizes all routines available for establishing a transport connection. Refer to man pages for the specifications on these routines.
Table 3-3 Routines for Establishing a Transport Connection
Command |
Description |
---|---|
t_accept |
Accepts a request for a transport connection |
Establishes a connection with the transport user at a specified destination |
|
Listens for connect request from another transport user |
|
Completes connection establishment if t_connect was called in asynchronous mode (see "Advanced Topics") |
The data transfer phase lets users transfer data in both directions via the connection. t_snd() sends and t_rcv() receives data through the connection. It is assumed that all data sent by one user is guaranteed to be delivered to the other user in the order in which it was sent. Table 3-4 summarizes the connection mode data-transfer routines.
Table 3-4 Connection Mode Data Transfer Routines
Command |
Description |
---|---|
Receives data that has arrived over a transport connection |
|
Sends data over an established transport connection |
XTI/TLI has two types of connection release. The abortive release directs the transport provider to release the connection immediately. Any previously sent data that has not yet been transmitted to the other user may be discarded by the transport provider. t_snddis() initiates the abortive disconnect. t_rcvdis() receives the abortive disconnect. All transport providers usually support some form of abortive release procedure.
Some transport providers also support an orderly release that terminates communication without discarding data. t_sndrel() and t_rcvrel() perform this function. Table 3-5 summarizes the connection release routines. Refer to man pages for the specifications on these routines.
Table 3-5 Connection Release Routines
Command |
Description |
---|---|
Returns a reason code for a disconnection and any remaining user data |
|
Acknowledges receipt of an orderly release of a connection request |
|
Aborts a connection or rejects a connect request |
|
Requests the orderly release of a connection |