HP 9000 Networking XTI Programmer's Guide

XTI over TCP/UDP Networks

Generating XTI states via TCP state bits

TCP uses special messages such as SYN, FIN, and RST to indicate a TCP

connection’s state transitions. These TCP states need to be translated into the

explicit state transitions speciﬁed by XTI. Internally, these TCP events are

recorded in the following state bits:

#define SS_ISCONNECTED 0x0002 /* socket connected to a peer */

#define SS_ISCONNECTING 0x0004 /* in process connect to peer */

#define SS_ISDISCONNECTING 0x0008 /* process disconnecting */

#define SS_CANTSENDMORE 0x0010 /* can’t send peer more data */

#define SS_CANTRCVMORE 0x0020 /* can’t recv more from peer */

#define SS_RCVATMARK 0x0040 /* at mark on input */

For example, if SS_CANTRCVMORE is set, but SS_CANTSENDMORE is

reset, we interpret that the connection received a T_ORDREL event. The

connection enters the T_INREL state, and we generate a T_ORDREL_IND

which can be consumed by a t_rcvrel() call.

Because XTI events and states must be interpreted, some events will not be

generated. For example, a node that sends a T_ORDREL request will never

receive a T_ORDREL_IND from the remote node, because if the ﬂags

SS_CANTSENDMORE and SS_CANTRCVMORE are both set, we interpret

this state to be a T_DISCON event.

Another XTI state that has different semantics is how connections are

handled. TCP connections are completed internally in the transport code;

therefore, when t_listen() returns to you the connection is already made. The

initiating nodes t_connect() returns successfully as soon as the remote TCP

completes the connection, not when the remote user calls t_accept().

conn_req -> conn_ind

conn_res <- tcp generates this