t_accept(3)t_accept(3)NAMEt_accept - Accept a connect request
SYNOPSIS
#include <xti.h>
int t_accept
int fd,
int resfd,
struct t_call *call );
LIBRARY
XTI Library (libxti.a)
STANDARDS
Interfaces documented on this reference page conform to industry stan‐
dards as follows:
t_accept(): XNS4.0, XNS5.0
Refer to the standards(5) reference page for more information about
industry standards and associated tags.
PARAMETERS
The following table summarizes the relevance of input and output param‐
eters before and after t_accept() is called:
──────────────────────────────────────────────
Parameter Before Call After Call
──────────────────────────────────────────────
fd y n
resfd y n
call->addr.maxlen n n
call->addr.len y n
call->addr.buf o(o) n
call->opt.maxlen n n
call->opt.len y n
call->opt.buf o(o) n
call->udata.maxlen n n
call->udata.len y n
call->udata.buf o(o) n
call->sequence y n
──────────────────────────────────────────────
Notes to table: This is a meaningful parameter. This is not a meaning‐
ful parameter. This is an optional parameter. The content of the
object pointed to by o is optional. Specifies a file descriptor
returned by the t_open() function that identifies the local transport
endpoint from which the connect indication arrived. Specifies the
local transport endpoint where the connection is to be established. A
transport user can accept a connection either on the same or on a dif‐
ferent local transport endpoint than the one on which the connect indi‐
cation arrived.
Before accepting the connection on the same transport endpoint
(resfd == fd), the transport user must have responded to any
previous connect indications received on that same transport
endpoint using the t_accept() or t_snddis() functions. Other‐
wise, the t_accept() function fails and sets t_errno to [TIND‐
OUT].
When a different transport endpoint (resfd != fd) is specified,
the transport user can bind the transport endpoint with a call
to the t_bind() function prior to issuing the t_accept() call.
If the endpoint is not bound prior to call to t_accept(), the
transport provider automatically binds it to the same protocol
address to which fd is bound. If the transport user decides to
bind the endpoint, the req->qlen parameter of t_bind() must be
set to 0 (zero) and the endpoint must be in the T_IDLE state
(refer to the t_getstate() function) before the t_accept() func‐
tion is called.
When there are indications, such as connect or disconnect, wait‐
ing to be received at that endpoint, t_accept() fails and sets
t_errno to [TLOOK]. Points to a type t_call structure used to
store information required by the transport provider to complete
the connection. The t_call structure has the following four mem‐
bers: Specifies a buffer for protocol address information sent
by the calling transport user. The address can be null (zero
length). If it is not null, XTI may check it.
The type netbuf structure referenced by this member is defined
in the xti.h include file. This structure, which is used to
define buffer parameters, has the following members: Specifies
the maximum byte length of the data buffer. Specifies the
actual byte length of data written to the buffer. Points to the
buffer location. Specifies parameters or options associated
with the connection.
The values of parameters specified by call->opt and the syntax
of those values are protocol-specific. If the user sets
call->opt.len to zero (does not specify any options), the con‐
nection is assumed to be accepted unconditionally. The transport
provider can choose options other than the defaults to ensure
that the connection is accepted successfully. Specifies parame‐
ters of user data returned to the calling transport user from
the called transport user.
The amount of user data must not exceed the limits specified by
the transport provider as returned in the info->connect parame‐
ter of the t_open() and t_getinfo() functions. When the
call->udata.len parameter is 0 (zero), no data is sent to the
calling transport user.
The maxlen fields are meaningless. Specifies a unique identifi‐
cation number returned by the t_listen function and used to
identify the previously received connect indication.
The call->sequence parameter is a value returned by the t_lis‐
ten() function that uniquely associates the response with a pre‐
viously received connect indication.
DESCRIPTION
The t_accept() function is an XTI connection-oriented service function
that is issued by a transport user to accept a connect request after a
connect indication has arrived. Structures of types t_call and netbuf,
which are defined in the xti.h include file, are used by this function.
NOTES
Some transport providers do not distinguish between a connection indi‐
cation and the connection itself. If the connection is already estab‐
lished after t_listen() returns 0 (success), t_accept() assigns the
existing connection to the transport endpoint specified by resfd. See
xti_internet(7) for more information.
RETURN VALUES
Upon successful completion, a value of 0 (zero) is returned. Otherwise,
a value of -1 is returned and t_errno is set to indicate the error.
ERRORS
If the t_accept() function fails, t_errno may be set to one of the fol‐
lowing: The user does not have permission to accept a connection on the
responding transport endpoint or to use the specified options. The
specified protocol address was in an incorrect format or contained
illegal information. The amount of user data specified was not within
the bounds allowed by the transport provider. The fd or resfd file
descriptor does not refer to a transport endpoint, or the user is ille‐
gally accepting a connection on the same transport endpoint on which
the connect indication arrived. The specified options were in an
incorrect format or contained illegal information. An invalid sequence
number was specified. The function was called with identical fd and
the resfd parameters, but the endpoint still has outstanding connection
indications. You can either reject the connection indications with the
t_snddis() function or accept them on a different endpoint with the
t_accept() function. An asynchronous event has occurred on the trans‐
port endpoint referenced by the fd parameter and requires immediate
attention. This function is not supported by the underlying transport
provider. The t_accept() function was called in the wrong sequence at
the transport endpoint referenced by the fd parameter, or the transport
endpoint referred to by the resfd parameter is not in the appropriate
state. The fd and the resfd parameters do not refer to the same trans‐
port provider. An unspecified communication problem has occurred
between XTI and the transport provider. The fd and resfd parameters
are not bound to the same address. The endpoint referenced by the
resfd parameter, provided resfd does not equal fd, was bound to a pro‐
tocol address with a qlen greater than zero. A system error occurred
during execution of this function.
VALID STATES
The t_accept() function can only be called in the following transport
provider states: For fd, T_INCON. For fd != resfd, T_IDLE or T_UNBND.
SEE ALSO
Functions: t_alloc(3), t_bind(3), t_connect(3), t_getstate(3), t_lis‐
ten(3), t_open(3), t_optmgmt(3), t_rcvconnect(3).
Standards: standards(5).
Network Information: xti(7), xti_internet(7).
Network Programmer's Guide
t_accept(3)
