 |
Index for
Section 3 |
|
 |
Alphabetical
listing for T |
|
 |
Bottom of
page |
|
t_accept(3)
NAME
t_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 standards
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 parameters
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:
y This is a meaningful parameter.
n This is not a meaningful parameter.
o This is an optional parameter.
(o) The content of the object pointed to by o is optional.
fd Specifies a file descriptor returned by the t_open() function that
identifies the local transport endpoint from which the connect
indication arrived.
resfd
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 different local transport endpoint than the one on which
the connect indication 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. Otherwise, the t_accept() function
fails and sets t_errno to [TINDOUT].
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() function is called.
When there are indications, such as connect or disconnect, waiting to
be received at that endpoint, t_accept() fails and sets t_errno to
[TLOOK].
call
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 members:
struct netbuf addr
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:
unsigned int maxlen
Specifies the maximum byte length of the data buffer.
unsigned int len
Specifies the actual byte length of data written to the buffer.
char *buf
Points to the buffer location.
struct netbuf opt
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 connection is assumed
to be accepted unconditionally. The transport provider can choose
options other than the defaults to ensure that the connection is
accepted successfully.
struct netbuf udata
Specifies parameters 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 parameter 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.
int sequence
Specifies a unique identification 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_listen()
function that uniquely associates the response with a previously
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 indication
and the connection itself. If the connection is already established 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
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 fd or resfd file descriptor does not refer to a transport endpoint,
or the user is illegally accepting a connection on the same transport
endpoint on which the connect indication arrived.
[TBADOPT]
The specified options were in an incorrect format or contained illegal
information.
[TBADSEQ]
An invalid sequence number was specified.
[TINDOUT]
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.
[TLOOK]
An asynchronous event has occurred on the transport endpoint referenced
by the fd parameter and requires immediate attention.
[TNOTSUPPORT]
This function is not supported by the underlying transport provider.
[TOUTSTATE]
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.
[TPRIVMISMATCH]
The fd and the resfd parameters do not refer to the same transport
provider.
[TPROTO]
An unspecified communication problem has occurred between XTI and the
transport provider.
[TRESADDR]
The fd and resfd parameters are not bound to the same address.
[TRESQLEN]
The endpoint referenced by the resfd parameter, provided resfd does not
equal fd, was bound to a protocol address with a qlen greater than
zero.
[TSYSERR]
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_listen(3),
t_open(3), t_optmgmt(3), t_rcvconnect(3).
Standards: standards(5).
Network Information: xti(7), xti_internet(7).
Network Programmer's Guide
|
Index for
Section 3 |
|
|
Alphabetical
listing for T |
|
 |
Top of
page |
|