Technical Reference: Communications, Volume 2

t_accept Subroutine for X/Open Transport Interface

Library

X/Open Transport Interface Library (libxti.a)

Syntax

#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.

Parameters

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:

struct netbuf addr;
struct netbuf opt;
struct netbuf udata;
int sequence;

The fields within the structure have the following meanings:

addr: Specifies the protocol address of the calling transport user. The address of the caller may be null (length zero). When this field is not null, the field may be optionally checked by the X/Open Transport Interface.
opt: Indicates any options associated with the connection.
udata: Points to any user data to be returned to the caller.
sequence: Specifies the value returned by the t_listen subroutine which uniquely associates the response with a previously received connect indication.

Valid States

fd: T_INCON
resfd (Fd != resfd): T_IDLE

Return Values

0	Successful completion.
-1	Unsuccessful completion, t_errno is set to indicate an error.

Error Codes

On failure, t_errno is set to one of the following:

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.

Implementation Specifics

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).

Related Information

The t_connect subroutine, t_getstate subroutine, t_open subroutine, t_optmgmt subroutine, t_rcvconnect subroutine.