Legacy Document

Important: The information in this document is obsolete and should not be used for new development.

Inside Macintosh: Networking With Open Transport / Part 2 - Open Transport Reference

Chapter 22 - Endpoints Reference / Functions

OTAccept
Accepts an incoming connection request.

C INTERFACE
OSStatus OTAccept(EndpointRef ref, 
                     EndpointRef resRef, 
                     TCall* call);
C++ INTERFACE
OSStatus TEndpoint::Accept(EndpointRef resRef,
                     TCall* call);
PARAMETERS

ref
The endpoint reference of the listening endpoint.

resRef
The endpoint reference of the endpoint accepting the connection.

call
A pointer to a TCall structure that contains information about the address of the peer requesting the connection, option information, data associated with the connection request, and the connection ID for this connection.

The call->addr.buf field points to a buffer that contains the address of the peer that requested the connection. The provider may optionally check this address to ensure you're accepting the right connection. If you do not want to specify a value, set the call->addr.len field to 0.

The call->opt.buf field points to a buffer that contains option values for this connection. If you do not want to specify any options set the call->opt.len field to 0.

The call->udata.buf field points to a buffer containing any data to be returned to the endpoint requesting the connection. The call->udata.len field specifies the length of the data.

The call->sequence field specifies the connection ID of the connection request that you are accepting. This must be the same value that was passed to you by the OTListen function when you received the connection request.

function result
An error code. See Discussion.

DISCUSSION
You use the OTAccept function to accept a request that you retrieved using the OTListen function. You can accept a connection on either the same or a different endpoint than the one listening for connection request.

If you accept the connection on the same endpoint (the values of the ref and resRef parameters are the same), there must be no other outstanding connection requests on that endpoint. Otherwise, the call to OTAccept fails and returns the kOTIndOutErr result.
If you accept the connection on a different endpoint (the values of the ref and resRef parameters are different), you are not required to bind the endpoint accepting the request first. If the endpoint is not bound, the provider binds it to the same address as that of the endpoint receiving the connection request. If you want to bind it explicitly to that address, you must set the reqAddr->qlen field to 0.

If you do not wish to accept the connection request, you must call the OTSndDisconnect function.
If the endpoint is in synchronous mode, the function does not return until the operation is complete. If the endpoint is in asynchronous mode, the OTAccept function returns immediately with a kOTNoError result, indicating that processing has begun and that the client will be notified when it is complete.
When processing is finished and the connection is opened, the provider for the endpoint specified by the ref parameter calls that endpoint's notifier, passing the event T_ACCEPTCOMPLETE for the code parameter and the endpoint reference (ref) for the cookie parameter. The provider for the endpoint specified by the resRef parameter calls that endpoint's notifier, passing T_PASSCON for the code parameter and resRef for the cookie parameter. If you have accepted the connection on the same endpoint (ref and resRef are the same), the provider issues the T_ACCEPTCOMPLETE event first, and then the T_PASSCON event.

Note
It is possible, in the case where the listening and accepting endpoints are different, that the accepting endpoint receives a T_DATA event before receiving the T_PASSCON event. If this happens, set a flag to defer receiving the data until later. When the T_PASSCON event is received, check the flag and issue the OTRcv call if the flag is set. Note that after deferring the handling of the T_DATA event, your handler will not be notified of this event again, until you read all of the data presently available.
If you have not installed a notifier, you can poll the endpoint accepting the connection for a change of state to T_DATAXFER; the change of state happens when the connection is opened.

SPECIAL CONSIDERATIONS
In asynchronous mode, it is possible for the endpoint to issue the T_ACCEPTCOMPLETE event before the OTAccept function returns the result kOTNoError.
Not all endpoints support the sending of data with a connection request. Examine the connect field of the TEndpointInfo structure for the endpoint to determine if the endpoint supports the sending of data and the maximum size of the data.
Calling the OTAccept function on an endpoint that was bound with a qlen greater than 1 can result in the result kOTLookErr being returned because another T_LISTEN event or T_DISCONNECT event has arrived. For information on how to handle this situation, see "Handling Multiple Simultaneous Connections".

SEE ALSO
The OTBind function.
"TCP/IP Services"
"AppleTalk Reference".
Table 4-4.