Inside Macintosh: Open Transport /

Chapter 3 - Endpoints / Endpoints Reference

Functions / Establishing A Connection

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 (page 3-62) 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.

DESCRIPTION

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 on 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 and the endpoint must be in the T_IDLE state before calling the OTAccept function. If you want to bind it to a different address, there are no restrictions on the value of the eqAddr->qlen field.

If you do not wish to accept the request, you must call the OTSndDisconnect function.

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 T_ACCEPTCOMPLETE for the code parameter and kInvalidEndpointRef 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 ref 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.

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
kOTNoError result.

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.

The OTAccept function fails with the kOTLookErr error if there are indications (T_DISCONNECT or T_LISTEN) waiting to be received. This is because

Calling the OTAccept function on an endpoint that was bound with a qlen greater than 1 can result in a kOTLookErr being returned because another T_LISTEN event has arrived. Unfortunately, XTI specifies that the accept request cannot be acted on until the OTListen function has been called to receive this new connection request. This effectively means that you need to keep an array of outstanding connection requests. If you are acting on T_LISTEN events in your notifier, then you need to be able to handle having as many outstanding connection requests as you indicate in the qlen field, issuing an accept request, and getting a T_LISTENCOMPLETE event before the T_ACCEPTCOMPLETE event returns to you.

COMPLETION EVENT CODES

T_ACCEPTCOMPLETE

0x20000003

The OTAccept function has completed. The cookie parameter of the notifier function contains the endpoint reference of the endpoint to which the connection has been passed.

VALID STATES

Endpoint specified by the ref parameter: T_INCON

Endpoint specified by the resRef parameter: T_IDLE or T_UNBND

SEE ALSO

You use the OTListen function (page 3-125) to read a connection request before calling the OTAccept function to accept the request.

You use the TCall structure (page 3-62) to store 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.

You use the OTBind function (page 3-77) to bind the endpoint accepting the request explicitly and to specify the number of connection requests that can be outstanding for the endpoint.

You use the OTSndDisconnect function (page 3-149) to reject an incoming connection request.

For information on how to use this function with a TCP/IP protocol, see page 8-18 in the TCP/IP chapter.

You examine the connect field of the TEndpointInfo structure (page 3-48) to determine whether your endpoint supports the sending of data with a connection request.