Previous section.

Transport Provider Interface (TPI), Version 2 Draft 2
Copyright © 1999 The Open Group


T_CONN_RES - Connection Response


This message consists of one M_PROTO message block followed by zero or more M_DATA blocks if any user data is specified by the transport user. The format of the M_PROTO message block is as follows:

struct T_conn_res {
    t_scalar_t   PRIM_type;     /* always T_CONN_RES     */
    t_uscalar_t  ACCEPTOR_id;   /* accepting endpoint ID */
    t_scalar_t   OPT_length;    /* options length        */
    t_scalar_t   OPT_offset;    /* options offset        */
    t_scalar_t   SEQ_number;    /* sequence number       */


This primitive is sent by a transport user to the transport provider on a listening transport endpoint (hereafter, for brevity, referred to as the listener) on which the transport user received a T_CONN_IND. This primitive requests that the transport provider should accept the connection indication identified by SEQ_number on the response transport endpoint specified by ACCEPTOR_id.



identifies the primitive type.


identifies the transport provider endpoint which should be used to accept the connect request. The mapping of the contents of ACCEPTOR_id to the internal reference to a transport endpoint (often a pointer to a streams queue) is transport-provider defined. Some example mechanisms for using ACCEPTOR_id are given in Connection Acceptance.


is the length of the responding options.


is the offset from the beginning of the M_PROTO message block where the responding options begin.


is the sequence number which identifies the connection being responded to.

The proper alignment of the options in the M_PROTO message block is not guaranteed. The options in the M_PROTO message block are, however, aligned the same as they were received from the transport user.


The following rules apply when the transport endpoint referenced by ACCEPTOR_id is not the same as the listener:

In all cases, this primitive requires the transport provider to generate one of the following acknowledgments on receipt of the primitive, and the transport user wait for the acknowledgment before issuing any other primitives:


Correct acknowledgment of the primitive is indicated via the T_OK_ACK primitive described in reference TPI-SMD.

Non-fatal errors

These errors will be indicated via the
T_ERROR_ACK primitive described in reference TPI-SMD.


The allowable errors are as follows:


This indicates that the user did not have proper permissions for the use of the options or response id.


The specified protocol address (the one bound to the endpoint referenced by ACCEPTOR_id
) was in an incorrect format or contained illegal information.


The amount of user data specified was invalid.


This indicates that the response acceptor identifier was invalid.


This indicates that the options were in an incorrect format, or they contained invalid information.


The sequence number specified in the primitive was incorrect or invalid.


This primitive is not supported by the transport provider.


The primitive would place the transport interface out of state.


This indicates that the response ACCEPTOR_Id does not identify a transport provider of the same type as the listener.


The transport provider requires both transport endpoints (that is, the one referenced by ACCEPTOR_id
and the listener) to be bound to the same address.


The endpoint referenced by ACCEPTOR_id
was different from the listener, but was bound to a protocol address with a CONIND_number that is greater than zero.


A system error has occurred and the UNIX system error is indicated in the primitive.


Only connection-mode.


Transport user.

Contents Next section Index