*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->Tru64 Unix man pages -> t_accept (3)              
Title
Content
Arch
Section
 

t_accept(3)

Contents


NAME    [Toc]    [Back]

       t_accept - Accept a connect request

SYNOPSIS    [Toc]    [Back]

       #include <xti.h>

       int t_accept
               int fd,
               int resfd,
               struct t_call *call );

LIBRARY    [Toc]    [Back]

       XTI Library (libxti.a)

STANDARDS    [Toc]    [Back]

       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    [Toc]    [Back]

       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: This is a meaningful parameter.   This  is
       not  a  meaningful 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 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].
              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: 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 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.
  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.  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    [Toc]    [Back]

       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    [Toc]    [Back]

       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    [Toc]    [Back]

       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    [Toc]    [Back]

       If the t_accept() function fails, t_errno may  be  set  to
       one of the following: 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 illegally 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 transport 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 transport 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  protocol  address  with  a  qlen
       greater  than zero.  A system error occurred during execution
 of this function.

VALID STATES    [Toc]    [Back]

       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    [Toc]    [Back]

      
      
       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



                                                      t_accept(3)
[ Back ]
 Similar pages
Name OS Title
t_listen HP-UX listen for a connect request
t_listen Tru64 Listen for a connect request
t_listen IRIX listen for a connect request
ttdt_message_accept HP-UX accept a contract to handle a ToolTalk request
t_rcvconnect Tru64 Receive the confirmation from a connect request
t_rcvconnect IRIX receive the confirmation from a connect request
t_rcvconnect HP-UX receive the confirmation from a connect request
BIO_s_accept Tru64 Accept BIO
BIO_set_accept_bios Tru64 Accept BIO
BIO_s_accept NetBSD accept BIO
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service