T_BIND_ACK(D7tpi)
T_BIND_ACK --
Bind Protocol Address Acknowledgment
Synopsis
This message consists of one M_PCPROTO message block
formatted as follows:
struct T_bind_ack {
long PRIM_type; /* always T_BIND_ACK */
long ADDR_length; /* length of address - */
long ADDR_offset; /* offset of address */
unsigned long CONIND_number; /* connect indications
to be queued */
}
Description
This primitive indicates to the transport user that the specified
protocol address has been bound to the stream,
that the specified
number of connect indications are allowed to be queued by the transport
provider for the specified
protocol address, and that the stream associated with the
specified protocol address has been activated.
Parameters
PRIM_type-
indicates the primitive type.
ADDR_length-
is the length of the protocol address that was bound
to the stream and ADDR_offset is the offset from the
beginning of the
M_PCPROTO
block where the protocol address begins.
CONIND_number-
is the accepted number of connect indications
allowed to be outstanding by the transport provider for the specified protocol address.
The proper alignment of the address in the
M_PCPROTO
message block is not
guaranteed.
-
Note that
this field doesn't apply to connectionless transport providers.
Rules
The following rules apply to the binding of the specified protocol
address to the stream:
-
If the ADDR_length field in the T_BIND_REQ/O_T_BIND_REQ
primitive is
0, then the transport provider is to assign a transport protocol
address to the user.
-
The transport provider is to bind the transport
protocol address as specified in the
T_BIND_REQ/O_T_BIND_REQ
primitive.
-
If the transport provider cannot bind the specified address, it
may assign another address to the user if the primitive
O_T_BIND_REQ was used.
In this case, it is the transport user's responsibility to
check the protocol address
returned in the
T_BIND_ACK
primitive to see if it is the same as
the one requested, and take appropriate action.
If T_BIND_REQ was used, the provider should return an error.
The following rules apply to negotiating the CONIND_number
argument:
-
The returned value must be less than or equal to the corresponding requested
number as indicated in the
T_BIND_REQ/O_T_BIND_REQ
primitive.
-
If the requested value is greater than zero, the returned value must also
be greater than zero.
-
Only one
stream
that is bound to the indicated protocol address may have a
negotiated accepted number of maximum connect requests greater
than zero.
If a
O_T_BIND_REQ
primitive specifies a value greater than zero, but another stream
has already bound itself to the given protocol address with a
value greater than zero, the transport provider should assign
another protocol address to the user.
-
If a stream with CONIND_number greater than zero is used to
accept a connection,
the stream will be found busy
during the duration of that connection
and no other stream may be bound to that protocol address with a CONIND_number greater than zero.
This will prevent more than one stream bound to the identical protocol
address
from accepting connect indications.
-
A stream requesting a CONIND_number of zero should always be valid.
This indicates to the transport provider that the stream is to be
used to request connections only.
-
A stream with a negotiated CONIND_number greater than zero may
generate connect requests or accept connect indications.
Errors
If the above rules result in an error condition, then the transport
provider must issue an
T_ERROR_ACK
primitive to the transport user specifying the error as defined in the
description of the
T_BIND_REQ/O_T_BIND_REQ
primitive.
Modes
Both connection-mode and connectionless-mode.
Originator
Transport provider.
Notices
Hardware constraints
None
Applicability
N/A
Backward compatibility
UnixWare-specific TPI Message Formats
Forward compatibility
N/A
19 June 2005
© 2005 The SCO Group, Inc. All rights reserved.
OpenServer 6 and UnixWare (SVR5) HDK - June 2005