TPI Message Formats

SYNOPSIS

include <sys/types.h>
include <sys/ddi.h>

DESCRIPTION

Two types are used to build the TPI primitives. The normative definitions of t_scalar_t and t_uscalar_t are to be found in the Networking Services Specification (see the referenced XNS specification ), but are repeated here for informational purposes.

t_scalar_t and t_uscalar_t are, respectively, a signed and an unsigned opaque integral type of equal length of at least 32 bits¹.

NAME

T_ADDR_ACK - Protocol Address Acknowledgment

SYNOPSIS

This message consists of one M_PCPROTO message block formatted as follows:

struct T_addr_ack {
    t_scalar_t   PRIM_type;      /* Always T_ADDR_ACK */
    t_scalar_t   LOCADDR_length;
    t_scalar_t   LOCADDR_offset;
    t_scalar_t   REMADDR_length;
    t_scalar_t   REMADDR_offset;
};

DESCRIPTION

This primitive indicates to the transport user the local and remote protocol addresses currently associated with the transport endpoint.

PARAMETERS

The fields of this message have the following meanings:

PRIM_type

the primitive type.

LOCADDR_length

the length of the local address associated with the transport endpoint.

LOCADDR_offset

the offset from the beginning of the M_PCPROTO message block where the local address begins.

REMADDR_length

the length of the remote address associated with the transport endpoint.

REMADDR_offset

the offset from the beginning of the M_PCPROTO message block where the remote address begins.

The proper alignment of the addresses in the M_PCPROTO message block is not guaranteed.

RULES

If the transport endpoint is not bound to a local address, the LOCADDR_length field is set to 0.

If the transport endpoint is not associated with a remote address, the REMADDR_length field is set to 0.

MODES

Both connection-mode and connectionless-mode.

ORIGINATOR

Transport provider.

NAME

T_ADDR_REQ - Get Protocol Address Request

SYNOPSIS

This message consists of a M_PCPROTO message block formatted as follows:

struct T_addr_req {
    t_scalar_t   PRIM_type;      /* Always T_ADDR_REQ */
};

DESCRIPTION

This primitive requests the transport provider to return the local and remote protocol addresses currently associated with the transport endpoint.

PARAMETERS

PRIM_type

indicates the primitive type.

Note that the T_ADDR_REQ and T_ADDR_ACK primitives have no effect on the state of the transport provider and do not appear in the state tables.

RULES

This primitive requires the transport provider to generate one of the following acknowledgments on receipt of the primitive and that the transport user wait for the acknowledgment before issuing any other primitives:

Successful

Acknowledgment of the primitive via T_ADDR_ACK

Non-fatal errors

These errors will be indicated via T_ERROR_ACK.

MODES

Both connection-mode and connectionless-mode.

ORIGINATOR

Transport user.

NAME

T_BIND_ACK - Bind Protocol Address Acknowledgment

SYNOPSIS

This message consists of one M_PCPROTO message block formatted as follows:

struct T_bind_ack {
    t_scalar_t    PRIM_type;      /* Always T_BIND_ACK */
    t_scalar_t    ADDR_length;
    t_scalar_t    ADDR_offset;
    t_uscalar_t   CONIND_number;
};

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.

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.

Note that this field does not apply to connectionless transport providers.

The proper alignment of the address in the M_PCPROTO message block is not guaranteed.

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 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 primitive.

• If the transport provider cannot bind the specified address the provider will return [TADDRBUSY].

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 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 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 primitive.

MODES

Both connection-mode and connectionless-mode.

ORIGINATOR

Transport provider.

NAME

T_BIND_REQ - Bind Protocol Address Request

SYNOPSIS

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

struct T_bind_req {
    t_scalar_t    PRIM_type;      /* Always T_BIND_REQ */
    t_scalar_t    ADDR_length;
    t_scalar_t    ADDR_offset;
    t_uscalar_t   CONIND_number;
};

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.

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 choose 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 reference TPI-SMD.

ERRORS

The allowable errors are as follows:

[TACCES]

This indicates that the user did not have proper permissions for the use of the requested address.

[TADDRBUSY]

This indicates that the requested address is in use.

[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.

[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.

MODES

Both connection-mode and connectionless-mode.

ORIGINATOR

Transport user.

NAME

T_CONN_CON - Connection Confirm

SYNOPSIS

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

struct T_conn_con {
    t_scalar_t   PRIM_type;      /* Always T_CONN_CON         */
    t_scalar_t   RES_length;     /* Responding address length */
    t_scalar_t   RES_offset;
    t_scalar_t   OPT_length;
    t_scalar_t   OPT_offset;
};

DESCRIPTION

This primitive indicates to the user that a connect request has been confirmed on the specified responding address.

PARAMETERS

PRIM_type

identifies the primitive type.

RES_length

is the length of the responding address that the connection was accepted.

RES_offset

is the offset (from the beginning of the M_PROTO message block) where the responding address begins.

OPT_length

is the length of the confirmed options associated with the primitive.

OPT_offset

is the offset from the beginning of the M_PROTO message block) of the confirmed options associated with the primitive.

The proper alignment of the responding address and options in the M_PROTO message block is not guaranteed.

MODES

Only connection-mode.

ORIGINATOR

Transport provider.

NAME

T_CONN_IND - Connect Indication

SYNOPSIS

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

struct T_conn_ind {
    t_scalar_t   PRIM_type;      /* Always T_CONN_IND */
    t_scalar_t   SRC_length;
    t_scalar_t   SRC_offset;
    t_scalar_t   OPT_length;
    t_scalar_t   OPT_offset;
    t_scalar_t   SEQ_number;
};

DESCRIPTION

This primitive indicates to the transport user that a connect request to the user has been made by the user at the specified source address.

PARAMETERS

PRIM_type

identifies the primitive type.

SRC_length

is the length of the source address

SRC_offset

is the offset (from the beginning of the M_PROTO message block) where the source address begins.

OPT_length

is the length of the requested options associated with the primitive.

OPT_offset

is the offset (from the beginning of the M_PROTO message block) of the requested options associated with the primitive.

SEQ_number

should be a unique number other than -1 to identify the connect indication.

The proper alignment of the source address and options in the M_PROTO message block is not guaranteed.

MODES

Only connection-mode.

ORIGINATOR

Transport provider.

NAME

T_CONN_REQ - Connect Request

SYNOPSIS

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_req {
    t_scalar_t   PRIM_type;      /* Always T_CONN_REQ */
    t_scalar_t   DEST_length;
    t_scalar_t   DEST_offset;
    t_scalar_t   OPT_length;
    t_scalar_t   OPT_offset;
};

DESCRIPTION

This primitive requests that the transport provider connect to the specified destination.

PARAMETERS

PRIM_type

identifies the primitive type.

DEST_length

is the length of the destination address

DEST_offset

is the offset (from the beginning of the M_PROTO message block) where the destination address begins.

OPT_length

is the length of the requested options associated with the primitive.

OPT_offset

is the offset (from the beginning of the M_PROTO message block) of the requested options associated with the primitive.

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

Note:

The information located by the defined structures may not be in the proper alignment in the message blocks, so the casting of structure definitions over these fields may produce incorrect results. It is advised that the transport providers supply exact format specifications for the appropriate information to the transport users.

RULES

This primitive requires 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_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.

ERRORS

The allowable errors are as follows:

[TACCES]

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

[TADDRBUSY]

The transport provider does not support multiple connections to the same destination address. This error indicates that a connection already exists for the requested destination.

[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 connection errors, such as an unreachable destination. Those error types are indicated via the T_DISCON_IND primitive.

[TBADDATA]

The amount of user data specified was invalid.

[TBADOPT]

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

[TNOTSUPPORT]

This primitive is not supported by the transport provider.

[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.

MODES

Only connection-mode.

ORIGINATOR

Transport user.

NAME

T_CONN_RES - Connection Response

SYNOPSIS

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       */
};

DESCRIPTION

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.

PARAMETERS

PRIM_type

identifies the primitive type.

ACCEPTOR_id

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 .

OPT_length

is the length of the responding options.

OPT_offset

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

SEQ_number

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.

RULES

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

• If the endpoint referenced by ACCEPTOR_id is not bound at the time that the T_CONN_RES primitive is received by the transport provider, the transport provider will automatically bind that endpoint to the same protocol address as that to which the listener is bound.

• If the endpoint referenced by ACCEPTOR_id is already bound when the T_CONN_RES primitive was received by the transport provider, it must be bound to a protocol address with a CONIND_number of zero and must be in the TS_IDLE state.

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:

Successful

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.

ERRORS

The allowable errors are as follows:

[TACCES]

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

[TBADADDR]

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

[TBADDATA]

The amount of user data specified was invalid.

[TBADF]

This indicates that the response acceptor identifier was invalid.

[TBADOPT]

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

[TBADSEQ]

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

[TNOTSUPPORT]

This primitive is not supported by the transport provider.

[TOUTSTATE]

The primitive would place the transport interface out of state.

[TPROVMISMATCH]

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

[TRESADDR]

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.

[TRESQLEN]

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.

[TSYSERR]

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

MODES

Only connection-mode.

ORIGINATOR

Transport user.

NAME

T_DATA_IND - Data Indication

SYNOPSIS

This message consists of one M_PROTO message block followed by zero or more M_DATA message blocks where each M_DATA message block contains at least one byte of data. The format of the M_PROTO message block is as follows:

struct T_data_ind {
    t_scalar_t   PRIM_type;      /* Always T_DATA_IND */
    t_scalar_t   MORE_flag;
};

DESCRIPTION

This primitive indicates to the transport user that this message contains a transport interface data unit. One or more transport interface data units form a transport service data unit. This primitive has a mechanism which indicates the beginning and end of a transport service data unit. However, not all transport providers support the concept of a transport service data unit.

PARAMETERS

PRIM_type

identifies the primitive type.

MORE_flag

when greater than zero, indicates that the next T_DATA_IND primitive is also part of this transport service data unit.

RULES

If a TSDU spans multiple T_DATA_IND message blocks, then an ETSDU may be placed in between two T_DATA_IND message blocks. Once an ETSDU is started, then the ETSDU must be completed before any T_DATA_IND message blocks defining a TSDU is resumed.

MODES

Only connection-mode.

ORIGINATOR

Transport provider.

NAME

T_DATA_REQ - Data Request

SYNOPSIS

This message consists of one M_PROTO message block followed by zero or more M_DATA message blocks where each M_DATA message block contains zero or more bytes of data. The format of the M_PROTO message block is as follows:

struct T_data_req {
    t_scalar_t   PRIM_type;      /* Always T_DATA_REQ */
    t_scalar_t   MORE_flag;
};

DESCRIPTION

This primitive indicates to the transport provider that this message contains a transport interface data unit. One or more transport interface data units form a transport service data unit (TSDU).

Note that the maximum transport service data unit size allowed by the transport provider is indicated to the transport user via the T_INFO_ACK primitive.

This primitive has a mechanism which indicates the beginning and end of a transport service data unit. However, not all transport providers support the concept of a transport service data unit.

PARAMETERS

PRIM_type

identifies the primitive type.

MORE_flag

when greater than zero, indicates that the next T_DATA_REQ primitive is also part of this transport service data unit.

RULES

The transport provider must also recognize a message of one or more M_DATA message blocks without the leading M_PROTO message block as a T_DATA_REQ primitive. This message type will be initiated from the write(2) operating system service routine.

For example, on systems that support the tirdwr STREAMS module, if that module is pushed onto a stream corresponding to a transport provider supporting the TPI, then the write(2) operating system service routine may be used to send data on that transport endpoint. In this case there are no implied transport service data unit boundaries. Data is passed down the stream as a series of M_DATA messages.

This primitive does not require any acknowledgments, although it may generate a fatal error. This is indicated via a M_ERROR message type which results in the failure of all operating system service routines on the stream.

ERRORS

The allowable errors are as follows:

[EPROTO]

This indicates one of the following unrecoverable protocol conditions:

• The transport service interface was found to be in an incorrect state. If the interface is in the TS_IDLE state when the provider receives the T_DATA_REQ primitive, then the transport provider should just drop the message without generating a fatal error.

• The amount of transport user data associated with the primitive defines a transport service data unit larger than that allowed by the transport provider.

MODES

Only connection-mode.

ORIGINATOR

Transport user.

NAME

T_DISCON_IND - Disconnect Indication

SYNOPSIS

This message consists of a M_PROTO message block formatted as follows:

struct T_discon_ind {
    t_scalar_t   PRIM_type;      /* Always T_DISCON_IND */
    t_scalar_t   DISCON_reason;
    t_scalar_t   SEQ_number;
};

DESCRIPTION

This primitive indicates to the user that either a request for connection has been denied or an existing connection has been disconnected. The format of this message is one M_PROTO message block possibly followed by one or more M_DATA message blocks if there is any user data associated with the primitive.

PARAMETERS

PRIM_type

identifies the primitive type

DISCON_reason

is the reason for disconnect. The reason codes are protocol specific.

SEQ_number

is the sequence number which identifies which connect indication was denied, or it is -1 if the provider is disconnecting an existing connection.

RULES

The SEQ_number is only meaningful when this primitive is sent to a passive user who has the corresponding connect indication outstanding. It allows the transport user to identify which of its outstanding connect indications is associated with the disconnect.

MODES

Only connection-mode.

ORIGINATOR

Transport provider.

NAME

T_DISCON_REQ - Disconnect Request

SYNOPSIS

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

struct T_discon_req {
    t_scalar_t   PRIM_type;      /* Always T_DISCON_REQ */
    t_scalar_t   SEQ_number;
};

DESCRIPTION

This primitive requests that the transport provider deny a request for connection, or disconnect an existing connection.

PARAMETERS

PRIM_type

identifies the primitive type.

SEQ_number

identifies the outstanding connect indication that is to be denied. If the disconnect request is disconnecting an already existing connection, then the value of SEQ_number will be ignored.

RULES

This primitive requires the transport provider to generate the following acknowledgment 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_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.

ERRORS

The allowable errors are as follows:

[TBADDATA]

The amount of user data specified was invalid.

[TBADSEQ]

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

[TNOTSUPPORT]

This primitive is not supported by the transport provider.

[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.

MODES

Only connection-mode.

ORIGINATOR

Transport user.

NAME

T_ERROR_ACK - Error Acknowledgment

SYNOPSIS

This message consists of a M_PCPROTO message block formatted as follows:

struct T_error_ack {
    t_scalar_t   PRIM_type;      /* Always T_ERROR_ACK */
    t_scalar_t   ERROR_prim;     /* Primitive in error */
    t_scalar_t   TLI_error;
    t_scalar_t   UNIX_error;
};

DESCRIPTION

This primitive indicates to the transport user that a non-fatal error has occurred in the last transport-user-originated primitive.

For an overview of the error handling capabilities available to the transport provider see reference TPI-SMD.

PARAMETERS

PRIM_type

identifies the primitive.

ERROR_prim

identifies the primitive type that caused the error

TLI_error

contains the Transport Level Interface error code.

UNIX_error

contains the UNIX system error code. This may only be non zero if TLI_error is equal to TSYSERR.

RULES

This may only be initiated as an acknowledgment for those primitives that require one. It also indicates to the user that no action was taken on the primitive that caused the error.

ERRORS

The list of Transport Level Interface error codes are listed in Appendix F of the referenced XNS specification.

MODES

Both connection-mode and connectionless-mode.

ORIGINATOR

Transport provider.

NAME

T_EXDATA_IND - Expedited Data Indication

SYNOPSIS

This message consists of one M_PROTO message block followed by one or more M_DATA message blocks containing at least one byte of data. The format of the M_PROTO message block is as follows:

struct T_exdata_ind {
    t_scalar_t   PRIM_type;      /* Always T_EXDATA_IND */
    t_scalar_t   MORE_flag;
};

DESCRIPTION

This primitive indicates to the transport user that this message contains an expedited transport interface data unit. One or more expedited transport interface data units form an expedited transport service data unit.

This primitive has a mechanism which indicates the beginning and end of an expedited transport service data unit. However, not all transport providers support the concept of an expedited transport service data unit.

PARAMETERS

PRIM_type

identifies the primitive type.

MORE_flag

when greater than zero, indicates that the next T_EXDATA_IND primitive is also part of this expedited transport service data unit.

MODES

Only connection-mode.

ORIGINATOR

Transport provider.

NAME

T_EXDATA_REQ - Expedited Data Request

SYNOPSIS

This message consists of one M_PROTO message block followed by one or more M_DATA message blocks containing at least one byte of data. The format of the M_PROTO message block is as follows:

struct T_exdata_req {
    t_scalar_t   PRIM_type;      /* Always T_EXDATA_REQ */
    t_scalar_t   MORE_flag;
};

DESCRIPTION

This primitive indicates to the transport provider that this message contains an expedited transport interface data unit. One or more expedited transport interface data units form an expedited transport service data unit.

Note that the maximum size of a expedited transport service data unit is indicated to the transport user via the T_INFO_ACK primitive.

This primitive has a mechanism which indicates the beginning and end of an expedited transport service data unit. However, not all transport providers support the concept of an expedited transport service data unit.

PARAMETERS

PRIM_type

identifies the primitive type.

MORE_flag

when greater than zero indicates that the next T_EXDATA_REQ primitive is also part of this expedited transport service data unit.

RULES

This primitive does not require any acknowledgments, although it may generate a fatal error. This is indicated via a M_ERROR message type which results in the failure of all operating system service routines on the stream.

ERRORS

The allowable errors are as follows:

[EPROTO]

This indicates one of the following unrecoverable protocol conditions:

• The transport service interface was found to be in an incorrect state. If the interface is in the TS_IDLE state when the provider receives the T_EXDATA_REQ primitive, then the transport provider should just drop the message without generating a fatal error.

• The amount of transport user data associated with the primitive defines an expedited transport service data unit larger than that allowed by the transport provider.

MODES

Only connection-mode.

ORIGINATOR

Transport user.

NAME

T_INFO_ACK - Protocol Information Acknowledgment

SYNOPSIS

This message consists of a M_PCPROTO message block formatted as follows:

struct T_info_ack {
    t_scalar_t   PRIM_type;      /* Always T_INFO_ACK    */
    t_scalar_t   TSDU_size;      /* Max TSDU size        */
    t_scalar_t   ETSDU_size;     /* Max ETSDU size       */
    t_scalar_t   CDATA_size;     /* Connect data size    */
    t_scalar_t   DDATA_size;     /* Disconnect data size */
    t_scalar_t   ADDR_size;      /* TSAP size            */
    t_scalar_t   OPT_size;       /* Options size         */
    t_scalar_t   TIDU_size;      /* TIDU size            */
    t_scalar_t   SERV_type;      /* Service type         */
    t_scalar_t   CURRENT_state;  /* Current state        */
    t_scalar_t   PROVIDER_flag;  /* Provider flag        */
};

DESCRIPTION

This primitive indicates to the transport user any relevant protocol-dependent parameters. It should be initiated in response to the T_INFO_REQ primitive described above. The format of this message is one M_PCPROTO message block.

PARAMETERS

The fields of this message have the following meanings:

PRIM_type

This indicates the primitive type.

TSDU_size

A value greater than zero specifies the maximum size of a transport service data unit (TSDU); a value of zero specifies that the transport provider does not support the concept of TSDU, although it does support the sending of a data stream with no logical boundaries preserved across a connection; a value of -1 specifies that there is no limit on the size of a TSDU; and a value of -2 specifies that the transfer of normal data is not supported by the transport provider.

ETSDU_size

A value greater than zero specifies the maximum size of an expedited transport service data unit (ETSDU); a value of zero specifies that the transport provider does not support the concept of ETSDU, although it does support the sending of an expedited data stream with no logical boundaries preserved across a connection; a value of -1 specifies that there is no limit on the size of an ETSDU; and a value of -2 specifies that the transfer of expedited data is not supported by the transport provider.

CDATA_size

A value greater than or equal to zero specifies the maximum amount of data that may be associated with connection establishment primitives; and a value of -2 specifies that the transport provider does not allow data to be sent with connection establishment primitives.

DDATA_size

A value greater than or equal to zero specifies the maximum amount of data that may be associated with the disconnect primitives; and a value of -2 specifies that the transport provider does not allow data to be sent with the disconnect primitives.

ADDR_size

A value greater than or equal to zero indicates the maximum size of a transport protocol address; and a value of -2 specifies that the transport provider does not provide user access to transport protocol addresses.

OPT_size

A value greater than or equal to zero indicates the maximum number of bytes of protocol-specific options supported by the provider; and a value of -2 specifies that the transport provider does not support user-settable options.

TIDU_size

This is the amount of user data that may be present in a single T_DATA_REQ or T_EXDATA_REQ primitive. This is the size of the transport protocol interface data unit, and should not exceed the tunable system limit, if non-zero, for the size of a STREAMS message.

SERV_type

This field specifies the service type supported by the transport provider, and is one of the following:

T_COTS

The provider service is connection oriented with no orderly release support.

T_COTS_ORD

The provider service is connection oriented with orderly release support.

T_CLTS

The provider service is a connectionless transport service.

CURRENT_state

This is the current state of the transport provider.

PROVIDER_flag

This field specifies additional properties specific to the transport provider and may alter the way the transport user communicates. The following flags may be set by the provider:

SENDZERO

This flag indicates that the transport provider supports the sending of zero-length TSDUs.

XPG4_1

This flag indicates that the transport provider supports XPG4 semantics.

RULES

The following rules apply when the type of service is T_CLTS:

• The ETSDU_size, CDATA_size and DDATA_size fields should be -2.

• The TSDU_size should equal the TIDU_size.

MODES

Both connection-mode and connectionless-mode.

ORIGINATOR

Transport provider.

NAME

T_INFO_REQ - Get Transport Protocol Parameter Sizes

SYNOPSIS

This message consists of a M_PCPROTO message block formatted as follows:

struct T_info_req {
    t_scalar_t   PRIM_type;      /* Always T_INFO_REQ */
};

DESCRIPTION

This primitive requests the transport provider to return the sizes of all relevant protocol parameters, plus the current state of the provider.

PARAMETERS

PRIM_type

indicates the primitive type.

Note that the T_INFO_REQ and T_INFO_ACK primitives have no effect on the state of the transport provider and do not appear in the state tables.

RULES

This primitive requires the transport provider to generate one of the following acknowledgments on receipt of the primitive and that the transport user wait for the acknowledgment before issuing any other primitives:

Successful

Acknowledgment of the primitive via the T_INFO_ACK.

Non-fatal errors

There are no errors associated with this primitive.

MODES

Both connection-mode and connectionless-mode.

ORIGINATOR

Transport user.

NAME

T_OK_ACK - Success Acknowledgment

SYNOPSIS

This message consists of one M_PCPROTO message block formatted as follows:

struct T_ok_ack {
    t_scalar_t   PRIM_type;      /* Always T_OK_ACK */
    t_scalar_t   CORRECT_prim;
};

DESCRIPTION

This primitive indicates to the transport user that the previous transport-user-originated primitive was received successfully by the transport provider. It does not indicate to the transport user any transport protocol action taken due to issuing the T_INFO_REQ primitive. This may only be initiated as an acknowledgment for those primitives that require one.

PARAMETERS

PRIM_type

identifies the primitive.

CORRECT_prim

contains the successfully received primitive type.

MODES

Both connection-mode and connectionless-mode.

ORIGINATOR

Transport provider.

NAME

T_OPTDATA_IND - Data indication with options

SYNOPSIS

The message consists of one M_PROTO message block followed by zero or more message blocks, where each M_DATA message block contains one or more bytes of data. The format of the M_PROTO message block is as follows:

struct T_optdata_ind {
    t_scalar_t PRIM_type;      /* always T_OPTDATA_IND           */
    t_scalar_t DATA_flag;      /* flag bits associated with data */
    t_scalar_t OPT_length;     /* options length                 */
    t_scalar_t OPT_offset;     /* options offset                 */
};

DESCRIPTION

The primitive indicates to the transport user that the message contains a transport interface data unit. One or more transport interface data units form a transport service data unit (TSDU).

Note that the maximum transport service and data unit sizes allowed by a transport provider is indicated to the user by the T_INFO_ACK primitive.

This primitive has a mechanism that indicates the beginning and end of a transport service data unit. However not all transport providers support the concept of a transport service data unit.

This primitive also provides mechanisms to have options associated with the data being transferred.

PARAMETERS

The fields of this message have the following semantics:

PRIM_type

identifies the primitive type

DATA_flag

specifies bit fields specific general properties associated with the data being transferred. The following settings are currently defined:

T_ODF_MORE

When set, this bit indicates that the next T_OPTDATA_IND primitive is also part of this transport service data unit.

OPT_length

the length of the requested options asociated with the primitive

OPT_offset

the offset (from the beginning of the M_PROTO message block) where the options asociated with this primitive begin.

RULES

If a TSDU spans multiple T_OPTDATA_IND message blocks, then an ETSDU may be placed between two T_DATA_IND message blocks. Once an ETSDU is started, then the ETSDU must be completed before any T_OPTDATA_IND message blocks defining a TSDU are resumed.

MODES

Only connection mode.

ORIGINATOR

Transport provider.

NAME

T_OPTDATA_REQ - Data request with options

SYNOPSIS

The message consists of one M_PROTO message block followed by zero or more message blocks, where each M_DATA message block contains zero or more bytes of data. The format of the M_PROTO message block is as follows:

struct T_optdata_req {
   t_scalar_t PRIM_type;       /* always T_OPTDATA_REQ           */
   t_scalar_t DATA_flag;       /* flag bits associated with data */
   t_scalar_t OPT_length;      /* options length                 */
   t_scalar_t OPT_offset;      /* options offset                 */
};

DESCRIPTION:

The primitive indicates to the transport provider that the message contains a transport interface data unit. One or more transport interface data units form a transport service data units (TSDU).

Note that the maximum transport service and data unit sizes allowed by transport provider is indicated to the user by the T_INFO_ACK primitive.

This primitive has a mechanism that indicates the beginning and end of a transport service data unit. However not all transport providers support the concept of a transport service data unit.

This primitive also provides mechanisms to have options associated with the data being transferred.

PARAMETERS

The fields of this message have the following semantics:

PRIM_type

identifies the primitive type

DATA_flag

This field specifies bit fields specific general properties associated with the data being transferred. The following settings are currently defined:

T_ODF_MORE

When set, this bit indicates that the next T_OPTDATA_REQ primitive is also part of this transport service data unit.

OPT_length

the length of the requested options asociated with the primitive

OPT_offset

the offset (from the beginning of the M_PROTO message block) where the options asociated with this primitive begin.

RULES

It is possible to use this primitive with no associated options, in which case the OPT_length field is zero.

The primitive does not require any acknowledgements, although it may generate a fatal error. This is indicated via a M_ERROR message type, which results in the failure of all operating system service routines on the stream.

ERRORS

The allowable errors are as follows:

[EPROTO]

This indicates of the following unrecoverable protocol conditions:

• The transport service interface was found to be in an incorrect state. If the interface is in TS_IDLE state when the provider receives the T_OPTDATA_REQ primitive, then the transport provider should just drop the message without generating a fatal error.

• The amount of transport user data associated with the primitive defines a transport service data unit larger than that allowed by the transport provider.

MODES

Only connection mode

ORIGINATOR

Transport user

NAME

T_OPTMGMT_ACK - Option Management Acknowledgment

SYNOPSIS

This message consists of a M_PCPROTO message block formatted as follows:

struct T_optmgmt_ack {
    t_scalar_t   PRIM_type;      /* Always T_OPTMGMT_ACK */
    t_scalar_t   OPT_length;
    t_scalar_t   OPT_offset;
    t_scalar_t   MGMT_flags;
};

DESCRIPTION

This indicates to the transport user that the options management request has completed.

PARAMETERS

PRIM_type

indicates the primitive type

OPT_length

is the length of the protocol options associated with the primitive

OPT_offset

is the offset from the beginning of the M_PCPROTO block where the options begin.

The proper alignment of the options is not guaranteed. MGMT_flags should be the same as those specified in the T_OPTMGMT_REQ primitive with any additional flags as specified below.

RULES

The following rules apply to the T_OPTMGMT_ACK primitive.

• If the value of MGMT_flags in the T_OPTMGMT_REQ primitive is T_DEFAULT, the provider should return the default provider options without changing the existing options associated with the stream.

• If the value of MGMT_flags in the T_OPTMGMT_REQ primitive is T_CHECK, the provider should return the options as specified in the T_OPTMGMT_REQ primitive along with the additional flags T_SUCCESS or T_FAILURE which indicate to the user whether the specified options are supportable by the provider. The provider should not change any existing options associated with the stream.

• If the value of MGMT_flags in the T_OPTMGMT_REQ primitive is T_NEGOTIATE , the provider should set and negotiate the option as specified by the following rules:

  • If the OPT_length field of the T_OPTMGMT_REQ primitive is 0, then the transport provider is to set and return the default options associated with the stream in the T_OPTMGMT_ACK primitive.

  • If options are specified in the T_OPTMGMT_REQ primitive, then the transport provider should negotiate those options, set the negotiated options and return the negotiated options in the T_OPTMGMT_ACK primitive. It is the user's responsibility to check the negotiated options returned in the T_OPTMGMT_ACK primitive and take appropriate action.

• If the value of MGMT_flags in the T_OPTMGMT_REQ primitive is T_CURRENT, the provider should return the currently effective option values without changing any existing options associated with the stream.

ERRORS

If the above rules result in an error condition, the transport provider must issue a T_ERROR_ACK primitive to the transport user specifying the error as defined in the description of the T_OPTMGMT_REQ primitive.

MODES

Both connection-mode and connectionless-mode.

ORIGINATOR

Transport provider.

NAME

T_OPTMGMT_REQ - Options Management

SYNOPSIS

This message consists of a M_PROTO message block formatted as follows:

struct T_optmgmt_req {
    t_scalar_t   PRIM_type;      /* Always T_OPTMGMT_REQ */
    t_scalar_t   OPT_length;
    t_scalar_t   OPT_offset;
    t_scalar_t   MGMT_flags;
};

DESCRIPTION

This primitive allows the transport user to manage the options associated with the stream. The format of the message is one M_PROTO message block.

PARAMETERS

PRIM_type

indicates the primitive type

OPT_length

is the length of the protocol options associated with the primitive

OPT_offset

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

MGMT_flags

are the flags which define the request made by the transport user. The allowable flags are:

T_NEGOTIATE

Negotiate and set the options with the transport provider

T_CHECK

Check the validity of the specified options

T_DEFAULT

Return the default options

T_CURRENT

Return the currently effective option values.

The proper alignment of the options is not guaranteed. The options are, however, aligned the same as received from the transport user.

RULES

For the rules governing the requests made by this primitive see the T_OPTMGMT_ACK primitive.

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

Successful

Acknowledgment of the primitive via the T_OPTMGMT_ACK.

Non-fatal errors

These errors will be indicated via the T_ERROR_ACK primitive described in Overview of Error Handling Capabilities .

ERRORS

The allowable errors are as follows:

[TACCES]

The user did not have proper permissions for the use of the requested options.

[TBADFLAG]

The flags as specified were incorrect or invalid.

[TBADOPT]

The options as specified were in an incorrect format, or they contained invalid information.

[TOUTSTATE]

The primitive would place the transport interface out of state.

[TNOTSUPPORT]

This primitive is not supported by the transport provider.

[TSYSERR]

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

MODES

Both connection-mode and connectionless-mode.

Originator

Transport user.

NAME

T_ORDREL_IND - Orderly Release Indication

SYNOPSIS

This message consists of a M_PROTO message block formatted as follows:

struct T_ordrel_ind {
    t_scalar_t   PRIM_type;      /* Always T_ORDREL_IND */
};

DESCRIPTION

This primitive indicates to the transport user that the user on the other side of the connection is finished sending data. This primitive is only supported by the transport provider if it is of type T_COTS_ORD.

PARAMETERS

PRIM_type

identifies the primitive type.

MODES

Only connection-mode.

ORIGINATOR

Transport provider.

NAME

T_ORDREL_REQ - Orderly Release Request

SYNOPSIS

This message consists of a M_PROTO message block formatted as follows:

struct T_ordrel_req {
    t_scalar_t   PRIM_type;      /* Always T_ORDREL_REQ */
};

DESCRIPTION

This primitive indicates to the transport provider that the user is finished sending data. This primitive is only supported by the transport provider if it is of type T_COTS_ORD.

PARAMETERS

PRIM_type

identifies the primitive type.

RULES

This primitive does not require any acknowledgments, although it may generate a fatal error. This is indicated via a M_ERROR message type which results in the failure of all operating system service routines on the stream.

ERRORS

[EPROTO]

This indicates the unrecoverable protocol condition that the primitive would place the interface in an incorrect state.

MODES

Only connection-mode.

ORIGINATOR

Transport user.

NAME

T_UDERROR_IND - Unitdata Error Indication

SYNOPSIS

This message consists of a M_PROTO message block formatted as follows:

struct T_uderror_ind {
    t_scalar_t   PRIM_type;      /* Always T_UDERROR_IND */
    t_scalar_t   DEST_length;
    t_scalar_t   DEST_offset;
    t_scalar_t   OPT_length;
    t_scalar_t   OPT_offset;
    t_scalar_t   ERROR_type;
};

DESCRIPTION

This primitive indicates to the transport user that a datagram with the specified destination address and options produced an error.

PARAMETERS

PRIM_type

identifies the primitive type.

DEST_length

is the length of the destination address.

DEST_offset

is the offset (from the beginning of the M_PROTO message block) where the destination address begins.

OPT_length

is the length of the requested options associated with the primitive.

OPT_offset

is the offset (from the beginning of the M_PROTO message block) of the requested options associated with the primitive.

ERROR_type

defines the protocol dependent error code.

The proper alignment of the destination address and options in the M_PROTO message block is not guaranteed.

MODES

Only connectionless-mode.

ORIGINATOR

Transport provider.

NAME

T_UNBIND_REQ - Unbind Protocol Address Request

SYNOPSIS

This message consists of a M_PROTO message block formatted as follows:

struct T_unbind_req {
    t_scalar_t   PRIM_type;      /* Always T_UNBIND_REQ */
};

DESCRIPTION

This primitive requests that the transport provider unbind the protocol address associated with the stream and deactivate the stream.

PARAMETERS

PRIM_type

indicates the primitive type.

RULES

This primitive requires the transport provider to generate the following acknowledgments on receipt of the primitive and that the transport user must wait for the acknowledgment before issuing any other primitives:

Successful

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.

ERRORS

The allowable errors are as follows:

[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.

MODES

Both connection-mode and connectionless-mode.

ORIGINATOR

Transport user.

NAME

T_UNITDATA_IND - Unitdata Indication

SYNOPSIS

This message consists of one M_PROTO message block followed by zero or more M_DATA message blocks where each M_DATA message block contains at least one byte of data. The format of the M_PROTO message block is as follows:

struct T_unitdata_ind {
    t_scalar_t   PRIM_type;      /* Always T_UNITDATA_IND */
    t_scalar_t   SRC_length;
    t_scalar_t   SRC_offset;
    t_scalar_t   OPT_length;
    t_scalar_t   OPT_offset;
};

DESCRIPTION

This primitive indicates to the transport user that a datagram has been received from the specified source address.

PARAMETERS

PRIM_type

identifies the primitive type.

SRC_length

is the length of the source address.

SRC_offset

is the offset (from the beginning of the M_PROTO message block) where the source address begins.

OPT_length

is the length of the requested options associated with the primitive.

OPT_offset

is the offset (from the beginning of the M_PROTO message block) of the requested options associated with the primitive.

The proper alignment of the source address and options in the M_PROTO message block is not guaranteed.

MODES

Only connectionless-mode.

ORIGINATOR

Transport provider.

NAME

T_UNITDATA_REQ - Unitdata Request

SYNOPSIS

This message consists of one M_PROTO message block followed by zero or more M_DATA message blocks where each M_DATA message block contains zero or more bytes of data. The format of the M_PROTO message block is as follows:

struct T_unitdata_req {
    t_scalar_t   PRIM_type;      /* Always T_UNITDATA_REQ */
    t_scalar_t   DEST_length;
    t_scalar_t   DEST_offset;
    t_scalar_t   OPT_length;
    t_scalar_t   OPT_offset;
};

DESCRIPTION

This primitive requests that the transport provider send the specified datagram to the specified destination.

PARAMETERS

PRIM_type

identifies the primitive type.

DEST_length

is the length of the destination address

DEST_offset

is the offset (from the beginning of the M_PROTO message block) where the destination address begins.

OPT_length

is the length of the requested options associated with the primitive.

OPT_offset

is the offset (from the beginning of the M_PROTO message block) of the requested options associated with the primitive.

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

This primitive does not require any acknowledgment. If a non-fatal error occurs, it is the responsibility of the transport provider to report it via the T_UDERROR_IND indication. Fatal errors are indicated via a M_ERROR message type which results in the failure of all operating system service routines on the stream.

ERRORS

The allowable fatal errors are as follows:

[EPROTO]

This indicates one of the following unrecoverable protocol conditions:

• The transport service interface was found to be in an incorrect state.

• The amount of transport user data associated with the primitive defines an transport service data unit larger than that allowed by the transport provider.

MODES

Only connectionless-mode.

ORIGINATOR

Transport user.

Footnotes

1.

To forestall portability problems, it is recommended that applications should not use values larger than 2³² - 1.