HP-UX Reference (11i v3 07/02) - 3 Library Functions N-Z (vol 7)

t
t_accept(3) t_accept(3)
NAME
t_accept() - accept a connect request
SYNOPSIS
#include <xti.h> /* for X/OPEN Transport Interface - XTI */
/* or */
#include <tiuser.h> /* for Transport Layer Interface - TLI */
int t_accept (fd, resfd, call);
int fd;
int resfd;
struct t_call *call;
DESCRIPTION
The t_accept() function is issued by a transport user to accept a connect request. 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 com-
plete the connection. The parameter call points to a
t_call structure which contains the following
members:
struct netbuf addr; /* address */
struct netbuf opt; /* options */
struct netbuf udata; /* user data */
int sequence; /* sequence number */
The netbuf structure is defined in the <xti.h> or <tiuser.h> header file. This structure, which is
used to define buffer parameters, has the following members:
unsigned int maxlen maximum byte length of the data buffer
unsigned int len actual byte length of data written to buffer
char *buf points to buffer location
In call, the addr, opt, udata, and sequence parameters are explained here. addr is the protocol address of
the calling transport user. opt indicates any options associated with the connection. For XTI over the OSI
transport provider, this
netbuf should point to a struct of type isoco_options
. udata points to any
user data to be returned to the caller. sequence is the value returned by
t_listen() that uniquely asso-
ciates the response with a previously received connect indication. The address of the caller, addr, may be
null (length zero). When addr is not null, then it may optionally be checked by XTI.
A transport user may accept a connection on either the same, or on a different, local transport endpoint
than the one on which the connect indication arrived. Before the connection can be accepted on the same
endpoint (resfd==fd), the user must have responded to any previous connect indications received on that
transport endpoint (via
t_accept() or t_snddis() ). Otherwise, t_accept() will fail and set
t_errno to [TINDOUT].
If a different transport endpoint is specified (resfd!=fd), then the user may or may not choose to bind the
endpoint before t_accept() is issued. If the endpoint is not bound prior to the t_accept() , then the
transport provider will automatically bind it to the same protocol address fd is bound to. If the transport
user chooses to bind the endpoint, it must be bound to a protocol address with a qlen of zero and must be in
the
T_IDLE state before the t_accept() is issued.
The call to t_accept() will fail with t_errno set to [TLOOK] if there are indications for example, con-
nect or disconnect waiting to be received on the endpoint fd.
The udata argument 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 in the connect field of the
info argument of t_open() or t_getinfo() . If the len field of udata is zero, no data will be sent to
the caller. All the maxlen fields are meaningless.
When the user does not indicate any option (call->opt.len = 0), 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.
Valid States
fd: T_INCON
504 Hewlett-Packard Company − 1 − HP-UX 11i Version 3: February 2007