Accept a connect request.
X/Open Transport Interface Library (libxti.a)
#include <xti.h>
int t_accept (fd, resfd, call)
int fd;
int resfd;
const struct t_call *call;
The t_accept subroutine is issued by a transport user to accept a command request. A transport user may accept a connection on either the same local transport endpoint or on an endpoint different than the one on which the connect indication arrived.
Before the connection can be accepted on the same endpoint, the user must have responded to any previous connect indications received on that transport endpoint via the t_accept subroutine or the t_snddis subroutine. Otherwise, the t_accept subroutine will fail and set t_errno to TINDOUT.
If a different transport endpoint is specified, the user may or may not choose to bind the endpoint before the t_accept subroutine is issued. If the endpoint is not bound prior to the t_accept subroutine, the transport provider will automatically bind the endpoint to the same protocol address specified in the fd parameter. If the transport user chooses to bind the endpoint, it must be bound to a protocol address with a qlen field of zero (see the t_bind subroutine) and must be in the T_IDLE state before the t_accept subroutine is issued.
The call to the t_accept subroutine fails with t_errno set to TLOOK if there are indications (for example, connect or disconnect) waiting to be received on the endpoint specified by the fd parameter.
The value specfied in the udata field enables the called transport user to send user data to the caller. The amount of user data sent must not exceed the limits supported by the transport provider. This limit is specified in the connect field of the t_info structure of the t_open or t_getinfo subroutines. If the len field of udata is zero, no data is sent to the caller. All the maxlen fields are meaningless.
When the user does not indicate any option, it is assumed that the connection is to be accepted unconditionally. The transport provider may choose options other than the defaults to ensure that the connection is accepted successfully.
There may be transport provider-specific restrictions on address binding. See Appendix A, ISO Transport Protocol Information and Appendix B, Internet Protocol-specific Information.
Some transport providers do not differentiate between a connect indication and the connection itself. If the connection has already been established after a successful return of the t_listen subroutine, the t_accept subroutine will assign the existing connection to the transport endpoint specified by resfd (see Appendix B, Internet Protocol-specific Information).
Item | Description |
---|---|
fd | Identifies the local transport endpoint where the connect indication arrived. |
resfd | Specifies the local transport endpoint where the connection is to be established. |
call | 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 fields within the structure have the following meanings:
|
fd: T_INCON
resfd (Fd != resfd): T_IDLE
Item | Description |
---|---|
0 | Successful completion. |
-1 | Unsuccessful completion, t_errno is set to indicate an error. |
On failure, t_errno is set to one of the following:
Value | Description |
---|---|
TACCES | The user does not have permission to accept a connection on the responding transport endpoint or to use the specified options. |
TBADADDR | The specified protocol address was in an incorrect format or contained illegal information. |
TBADDATA | The amount of user data specified was not within the bounds allowed by the transport provider. |
TBADF | The file descriptor fd or resfd does not refer to a transport endpoint. |
TBADOPT | The specified options were in an incorrect format or contained illegal information. |
TBADSEQ | An invalid sequence number was specified. |
TINDOUT | The subroutine was called with the same endpoint, but there are outstanding connection indications on the endpoint. Those other connection indications must be handled either by rejecting them via the t_snddis subroutine or accepting them on a different endpoint via the t_accept subroutine. |
TLOOK | An asynchronous event has occurred on the transport endpoint referenced by fd and requires immediate attention. |
TNOTSUPPORT | This subroutine is not supported by the underlying transport provider. |
TOUTSTATE | The subroutine was called in the wrong sequence on the transport endpoint referenced by fd, or the transport endpoint referred to by resfd is not in the appropriate state. |
TPROTO | This error indicates that a communication problem has been detected between X/Open Transport Interface and the transport provider for which there is no other suitable X/Open Transport Interface(t_errno). |
TPROVMISMATCH | The file descriptors fd and resfd do not refer to the same transport provider. |
TRESADDR | This transport provider requires both fd and resfd to be bound to the same address. This error results if they are not. |
TRESQLEN | The endpoint referenced by resfd (where resfd is a different transport endpoint) was bound to a protocol address with a qlen field value that is greater than zero. |
TSYSERR | A system error has occurred during execution of this subroutine. |