Previous section.

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


T_CAPABILITY_ACK - protocol capability acknowledgment


This message consists of an M_PROTO or M_PCPROTO message containing a struct T_capability_ack which contains (at least) the following members:

int32_t             PRIM_type;    /* always T_CAPABILITY_ACK  */
                                  /* must be the first field! */
uint32_t            CAP_bits1;    /* capability bits #1       */
struct T_info_ack   INFO_ack;     /* info acknowledgement     */
uint32_t            ACCEPTOR_id;  /* accepting queue id       */


This primitive is the response to a T_CAPABILITY_REQ and informs the transport user of various provider information and feature capabilities as encoded in the field CAP_bits1. The provider must only set those bits which it supports and must leave as zero any bits not supported.


The fields of this message have the following meanings:


This indicates the primitive type and is always T_CAPABILITY_ACK. This field must be strictly the first field to allow receivers to determine the message type.


This is a 32-bit integer with zero or more of the following bits set, all other bits must be zero:


This bit indicates that the INFO_ack field contains the information which would have been returned in a T_INFO_ACK message at the same time.


This bit indicates that the ACCEPTOR_id field contains a unique identifier of this connection which is suitable for use in the ACCEPTOR_id field of the T_CONN_RES message.


In addition the following bit is reserved for future use: TC1_CAP_BITS2


This field is a sub-structure which contains an entire T_INFO_ACK message so that T_CAPABILITY_ACK can function as a replacement for that message. The contents are only valid if the TC1_INFO bit is set in CAP_bits1.


This field parallels the field of the same name in the T_CONN_RES message and, if the TC1_ACCEPTOR_ID bit is set in CAP_bits1, supplies a suitable value for use in the T_CONN_RES message.


If the T_CAPABILITY_REQ was an M_PCPROTO then this message must also be sent as an M_PCPROTO. Similarly if the T_CAPABILITY_REQ was an M_PROTO then this message must also be sent as an M_PROTO.


Both connection-mode and connectionless-mode.


Transport provider.

Contents Next section Index