T_BIND_REQ(D7tpi)

T_BIND_REQ, O_T_BIND_REQ -- Bind Protocol Address Request

Synopsis

These messages consist of one M_PROTO message block formatted as follows:

   struct T_bind_req {
       long PRIM_type;      /* always T_BIND_REQ or O_T_BIND_REQ */
       long ADDR_length;             /* length of address */
       long ADDR_offset;             /* offset of address */
       unsigned long CONIND_number;  /* requested number of connect
                                        indications to be queued */
   }

Description

These primitives request that the transport provider bind a protocol address to the stream, negotiate the number of connect indications allowed to be outstanding by the transport provider for the specified protocol address, and activate the stream associated with the protocol address.

Note that a stream is viewed as active when the transport provider may receive and transmit TPDUs (transport protocol data units) associated with the stream.

Parameters

PRIM_type

indicates the primitive type.

ADDR_length

is the length of the protocol address to be bound to the stream and ADDR_offset is the offset from the beginning of the M_PROTO block where the protocol address begins.

Note that all lengths, offsets, and sizes in all structures refer to the number of bytes.

CONIND_number

is the requested number of connect indications allowed to be outstanding by the transport provider for the specified protocol address.

Note that the CONIND_number should be ignored by those providing a connectionless transport service.
Also note that if the number of outstanding connect indications equals CONIND_number, the transport provider need not discard further incoming connect indications, but may chose to queue them internally until the number of outstanding connect indications drops below CONIND_number.

The proper alignment of the address in the M_PROTO message block is not guaranteed. The address in the M_PROTO message block is however, aligned the same as it was received from the transport user.

Rules

For rules governing the requests made by these primitives see the T_BIND_ACK primitive.

These primitives require the transport provider to generate one of the following acknowledgments on receipt of the primitive, and the transport user must wait for the acknowledgment before issuing any other primitives:

Successful: Correct acknowledgment of the primitive is indicated via the T_BIND_ACK primitive.
Non-fatal errors: These errors will be indicated via the T_ERROR_ACK primitive described in

Errors

The allowable errors are as follows:

TBADADDR: This indicates that the protocol address was in an incorrect format or the address contained invalid information. It is not intended to indicate protocol errors.
TNOADDR: This indicates that the transport provider could not allocate an address.
TACCES: This indicates that the user did not have proper permissions for the use of the requested address.
TOUTSTATE: The primitive would place the transport interface out of state.
TSYSERR: A system error has occurred and the UNIX system error is indicated in the primitive.
TADDRBUSY: This indicates that the requested address is in use. In other words, the transport user attempted to bind a protocol address to a second transport end point with a CONIND_number greater than zero. This error will only be returned for T_BIND_REQ. See T_BIND_ACK for the behavior of O_T_BIND_REQ in this instance.

Modes

Both connection-mode and connectionless-mode.

Originator

Transport user.

Notices

Hardware constraints

None

Applicability

N/A

Backward compatibility

UnixWare-specific TPI Message Formats

Forward compatibility

N/A