Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
HP-UX Reference > T


HP-UX 11i Version 3: February 2007

Technical documentation

» Feedback
Content starts here

 » Table of Contents

 » Index


t_accept() — accept a connect request


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


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 complete 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 associates 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, connect 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


resfd (fd != resfd): T_IDLE


There may be transport provider-specific restrictions on address binding.

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 t_listen(), t_accept() will assign the existing connection to the transport endpoint specified by resfd.

Fork Safety

t_accept is not fork-safe.


Upon successful completion, a value of 0 is returned. Otherwise, a value of -1 is returned, and t_errno is set to indicate the error.


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


The file descriptor, fd or resfd, does not refer to a transport endpoint, or the user is illegally accepting a connection of the same transport endpoint on which the connect indication arrived.


The function was issued 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.


The user does not have permission to accept a connection on the responding transport endpoint or use the specified options.


The specified options were 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 specified protocol address was in an incorrect format or contained illegal information.


An invalid sequence number was specified.


An asynchronous event has occurred on the transport endpoint referenced by fd and requires immediate attention.


This function is not supported by the underlying transport provider.


A system error has occurred during execution of this function.


The function was called with fd==resfd but there are outstanding connection indications on the endpoint. Those other connection indications must be handled either by rejecting them via t_snddis() or accepting them on a different endpoint via t_accept().


(XTI only) The file descriptors fd and resfd do not refer to the same transport provider.


The endpoint referenced by resfd (where resfd != fd) was bound to a protocol address with a qlen that is greater than zero.


(XTI only) This error indicates that a communication problem has been detected between XTI and the transport provider for which there is no other suitable XTI (t_errno).


This transport provider requires both fd and resfd to be bound to the same address. This error results if they are not.



XTI data structures


XTI data structures


TLI data structures


t_accept(): SVID2, XPG3, XPG4

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 1983-2007 Hewlett-Packard Development Company, L.P.