Inside Macintosh: Open Transport /

Chapter 3 - Endpoints / Endpoints Reference

Functions / Functions for Connectionless Transaction-Based Endpoints

OTSndUReply

Replies to a request sent by a client using a connectionless transaction-
based protocol.

C INTERFACE

OSStatus OTSndUReply (EndpointRef ref, TUnitReply* reply, 
                      OTFlags flags);

C++ INTERFACE

OSStatus TEndpoint::SndUReply(TUnitReply* reply, OTFlags flags);

PARAMETERS

ref

The endpoint reference of the endpoint sending the reply.

reply

A pointer to a TUnitReply structure (page 3-60) that specifies the ID of this transaction and the reply data.

reqFlags

A bitmapped long, which you can set to T_MORE to indicate that you are sending more reply data with a subsequent call to the OTSndUReply function.

DESCRIPTION

You use the OTSndUReply function to send a reply. The TUnitReply structure that you pass in the reply parameter specifies the address of the requester, the reply data, and any options you want to specify for this reply. If you do not specify the requester's address, the endpoint provider uses the transaction ID value stored in the sequence field of the reply parameter to match the reply against a pending request and knows in this way where to send the request.

If requests are acknowledged and the provider is not able to send the reply, the function returns with the kETimedOutErr result. If requests are not acknowledged, the function returns immediately, and you have no way of knowing whether the reply was received and read.

If requests are not acknowledged, the provider generates a T_REPLYCOMPLETE event for asynchronous responders even if the requester has not acknowledged receipt of the reply. Thus, the only way for you to know whether this event actually means that the reply was received, is to examine the reqFlags field of the req parameter for the OTRcvURequest function. If the T_ACKNOWLEDGED flag is set, then the T_REPLYCOMPLETE event indicates that your reply was received. The cookie parameter passed to the notifier to indicate completion is set to the reply parameter.

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

	Blocking	Nonblocking
Synchronous	The function returns when the provider lifts flow-control restrictions and the reply has been acknowledged or timed out (if the matching request was an acknowledged request).	For unacknowledged requests, the function returns immediately; for acknowledged requests, it returns when the reply has been acknowledged or time 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 acknow- ledged or timed out.	The function returns immediately. The provider calls your notifier, passing T_REPLYCOMPLETE for the code parameter when the reply is acknowledged or timed out.
	The kOTFlowErr result is never returned.	The kOTFlowErr result might be returned.

COMPLETION EVENT CODES

T_REPLYCOMPLETE

0x20000004

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

VALID STATES

T_IDLE

SEE ALSO

To determine the maximum size of the reply data, you must call the OTGetEndpointInfo function (page 3-82) and examine the tsdu field of the TEndpointInfo structure that it returns.

You use the TUnitReply structure (page 3-60) to specify the ID of this transaction and the reply data.

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

You use the OTCancelUReply function (page 3-119) to cancel an incoming request.

For information on how to use this function with the AppleTalk ATP protocol, see page 14-10 in the ATP chapter.

You examine the reqFlags field of the req parameter for the OTRcvURequest function (page 3-110) to determine whether the T_REPLYCOMPLETE event means that the reply was actually received.