Inside Macintosh: Open Transport /

Chapter 3 - Endpoints / Endpoints Reference

Functions / Functions for Connection-Oriented Transaction-Based Endpoints

OTSndReply

You use the OTSndReply function to reply to a connection-oriented transaction-
based request.

C INTERFACE

OSStatus OTSndReply (EndpointRef ref, TReply* reply, 
                     OTFlags* replyFlags);

C++ INTERFACE

OSStatus TEndpoint::SndReply(TReply* reply, OTFlags flags);

PARAMETERS

ref

The endpoint reference of the endpoint reading the request.

reply

A pointer to a TReply structure (page 3-67) that specifies the reply data being sent, the transaction ID for this transaction, and any options you want to set.

replyFlags

A bitmapped long specifying whether the rest of the reply is being sent with a subsequent call to this function (T_MORE) or whether this is the complete reply (T_MORE not set).

DESCRIPTION

You use the OTSndReply function to reply to a request you have read using the OTRcvRequest function. The reply parameter contains the reply to be sent, and the replyFlags parameter specifies whether you are sending the entire reply with this send (T_MORE bit clear) or sending just part of the reply (T_MORE bit set). If you are using multiple sends to send the reply, you must set the T_MORE bit on each but the last send. The total size of the data you send using multiple sends must not exceed the value of the tsdu field of the TEndpointInfo structure for this endpoint.

If the endpoint is in blocking mode, the OTSndReply function returns after it has sent the reply. If the endpoint is in nonblocking mode, the OTSndReply function returns the kOTFlowErr result if the endpoint provider is unable to send the reply because of flow-control restrictions. The provider issues the T_GODATA event when these restrictions are lifted. You can use the OTLook function to poll for this event, or you can use your notifier to handle it.

If the endpoint is in asynchronous mode, the provider calls your notifier when the OTSndReply function completes. The code parameter of the notifier function contains the T_REPLYCOMPLETE event, the cookie parameter contains the reply parameter passed with the OTSndReply function, and the result parameter contains the function result.

The next table shows how the endpoint's mode of execution and blocking status affects the behavior of the OTSndReply function.

	Blocking	Nonblocking
Synchronous	The function returns when the provider lifts flow-control restrictions and the reply has been successfully sent or timed out.	The function returns if flow- control restrictions are in effect or when the reply has been successfully sent or timed out.
	The kOTFlowErr result is never returned.	The kOTFlowErr result might be returned.
Asynchronous	The function returns immediately. The provider calls your notifier, passing T_REPLYCOMPLETE for the code parameter when the reply is successfully sent or timed out.	The function returns immediately. The provider calls your notifier, passing T_REPLYCOMPLETE for the code parameter when the reply is successfully sent or timed out.
	The kOTFlowErr result is never returned.	The kOTFlowErr result might be returned.

VALID STATES

T_DATAXFER, T_OUTREL

COMPLETION EVENTS

T_REPLYCOMPLETE

0x20000004

The OTSndReply function has completed. The cookie parameter of the notifier function points to the reply parameter.

SEE ALSO

You use the OTRcvRequest function (page 3-139) to read an incoming request before calling the OTSndReply function to reply to the request.

You use the TReply structure (page 3-67) to specify the reply data being sent, the transaction ID for this transaction, and any options you want to set.

The peer endpoint calls the OTRcvReply function (page 3-144) to acknowledge receiving the reply you send using the OTSndReply function.

You use the OTData structure (page 3-52) to transfer noncontiguous data.