Accepts a connect request.
Transport Layer Interface Library (libtli.a)
int t_accept (fd, resfd, call) int fd; int resfd; struct t_call *call;
The t_accept subroutine is issued by a transport user to accept a connect request. A transport user can accept a connection on either the same local transport end point or on an end point different from the one on which the connect indication arrived.
|Identifies the local transport end point where the connect indication arrived.
|Specifies the local transport end point where the connection is to be established.
| Contains information required by the transport provider to complete the connection. The call parameter points to a t_call structure, which contains the following members:
The netbuf structure is described in the tiuser.h file. In the call parameter, the addr field is the address of the caller, the opt field indicates any protocol-specific parameters associated with the connection, the udata field points to any user data to be returned to the caller, and the sequence field is the value returned by the t_listen subroutine which uniquely associates the response with a previously received connect indication.
If the same end point is specified (that is, the resfd value equals the fd value), the connection can be accepted unless the following condition is true: the user has received other indications on that end point, but has not responded to them (with either the t_accept or t_snddis subroutine). For this condition, the t_accept subroutine fails and sets the t_errno variable to TBADF.
If a different transport end point is specified (that is, the resfd value does not equal the fd value), the end point must be bound to a protocol address and must be in the T_IDLE state (see the t_getstate subroutine) before the t_accept subroutine is issued.
For both types of end points, the t_accept subroutine fails and sets the t_errno variable to TLOOK if there are indications (for example, a connect or disconnect) waiting to be received on that end point.
The values of parameters specified by the opt field and the syntax of those values are protocol-specific. The udata field enables the called transport user to send user data to the caller, the amount of user data must not exceed the limits supported by the transport provider as returned by the t_open or t_getinfo subroutine. If the value in the len field of the udata field is 0, no data will be sent to the caller.
On successful completion, the t_connect subroutine returns a value of 0. Otherwise, it returns a value of -1, and the t_errno variable is set to indicate the error.
If unsuccessful, the t_errno variable is set to one of the following:
|The user does not have permission to accept a connection on the responding transport end point or use the specified options.
|The amount of user data specified was not within the bounds allowed by the transport provider.
|The specified protocol address was in an incorrect format or contained illegal information.
|The specified file descriptor does not refer to a transport end point; or the user is illegally accepting a connection on the same transport end point on which the connect indication arrived.
|The specified options were in an incorrect format or contained illegal information.
|An incorrect sequence number was specified.
|An asynchronous event has occurred on the transport end point referenced by the fd parameter and requires immediate attention.
|This function is not supported by the underlying transport provider.
|The function was issued in the wrong sequence on the transport end point referenced by the fd parameter, or the transport end point referred to by the resfd parameter is not in the T_IDLE state.
|A system error has occurred during execution of this function.
This subroutine is part of the Base Operating System (BOS) Runtime.
The t_alloc subroutine, t_connect subroutine, t_getinfo subroutine, t_getstate subroutine, t_listen subroutine, t_open subroutine, t_rcvconnect subroutine and t_snddis subroutine.
List of Streams Programming References and STREAMS Overview in AIX Version 4.3 Communications Programming Concepts.