t_connect(3c) 맨 페이지 - 윈디하나의 솔라나라

개요

섹션
맨 페이지 이름
검색(S)

t_connect(3c)

Standard C Library Functions                                     t_connect(3C)



NAME
       t_connect - establish a connection with another transport user

SYNOPSIS
       #include <xti.h>

       int t_connect(int fd, const struct t_call *sndcall,
            struct t_call *rcvcall);

DESCRIPTION
       This  routine  is part of the XTI interfaces which evolved from the TLI
       interfaces. XTI represents the future evolution  of  these  interfaces.
       However,  TLI  interfaces are supported for compatibility. When using a
       TLI routine that has the same name as  an  XTI  routine,  the  tiuser.h
       header file must be used. Refer to the TLI  COMPATIBILITY section for a
       description of differences between the two  interfaces.  This  function
       enables  a transport user to request a connection to the specified des‐
       tination transport user.


       This function can only be issued in the T_IDLE state. The parameter  fd
       identifies  the  local  transport  endpoint where communication will be
       established, while sndcall and rcvcall  point  to  a  t_call  structure
       which contains the following members:

         struct netbuf addr;
         struct netbuf opt;
         struct netbuf udata;
         int sequence;



       The  parameter  sndcall  specifies  information needed by the transport
       provider to establish a connection and  rcvcall  specifies  information
       that is associated with the newly established connection.


       In  sndcall,  addr  specifies  the  protocol address of the destination
       transport user, opt presents  any  protocol-specific  information  that
       might  be  needed  by  the transport provider, udata points to optional
       user data that may be passed to the destination transport  user  during
       connection  establishment,  and  sequence has no meaning for this func‐
       tion.


       On return, in rcvcall, addr contains the  protocol  address  associated
       with  the  responding  transport endpoint, opt represents any protocol-
       specific information associated with the connection,  udata  points  to
       optional  user  data  that may be returned by the destination transport
       user during connection establishment, and sequence has no  meaning  for
       this function.


       The opt argument permits users to define the options that may be passed
       to the transport provider. The user may choose not to negotiate  proto‐
       col  options by setting the len field of opt to zero. In this case, the
       provider uses the option values currently set  for  the  communications
       endpoint.


       If  used, sndcall→opt.buf must point to a buffer with the corresponding
       options, and sndcall→opt.len must specify its length.  The  maxlen  and
       buf  fields  of  the  netbuf structure pointed by rcvcall→addr and rcv‐
       call→opt must be set before the call.


       The udata argument enables the caller to pass user data to the destina‐
       tion  transport  user  and  receive user data from the destination user
       during connection establishment. However, 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(3C)  or  t_get‐
       info(3C).  If the len of udata is zero in sndcall, no data will be sent
       to the destination transport user.


       On return, the addr, opt and udata fields of rcvcall will be updated to
       reflect  values  associated with the connection. Thus, the maxlen field
       of each argument must be set before issuing this function  to  indicate
       the  maximum size of the buffer for each. However, maxlen can be set to
       zero, in which case no information to this specific argument  is  given
       to  the  user on the return from t_connect(). If maxlen is greater than
       zero and less than the length of  the  value,  t_connect()  fails  with
       t_errno  set to TBUFOVFLW. If rcvcall is set to NULL, no information at
       all is returned.


       By default, t_connect() executes in synchronous mode, and will wait for
       the  destination  user's response before returning control to the local
       user. A successful return (that is, return  value  of  zero)  indicates
       that  the requested connection has been established. However, if O_NON‐
       BLOCK is set by means of t_open(3C) or fcntl(2),  t_connect()  executes
       in  asynchronous  mode.  In  this  case, the call will not wait for the
       remote user's response, but will  return  control  immediately  to  the
       local  user  and return -1 with t_errno set to TNODATA to indicate that
       the connection has not yet been established. In this way, the  function
       simply  initiates  the  connection establishment procedure by sending a
       connection request to the destination  transport  user.  The  t_rcvcon‐
       nect(3C)  function is used in conjunction with t_connect() to determine
       the status of the requested connection.


       When a synchronous t_connect() call is interrupted by the arrival of  a
       signal,  the state of the corresponding transport endpoint is T_OUTCON,
       allowing a further call to  either  t_rcvconnect(3C),  t_rcvdis(3C)  or
       t_snddis(3C).  When  an asynchronous t_connect() call is interrupted by
       the arrival of a signal, the state of the corresponding transport  end‐
       point is T_IDLE.

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

VALID STATES
       T_IDLE

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

       TACCES         The user does not have permission to use  the  specified
                      address or options.


       TADDRBUSY      This  transport  provider does not support multiple con‐
                      nections with the same local and remote addresses.  This
                      error indicates that a connection already exists.


       TBADADDR       The  specified protocol address was in an incorrect for‐
                      mat or contained illegal information.


       TBADDATA       The amount of user data specified  was  not  within  the
                      bounds allowed by the transport provider.


       TBADF          The specified file descriptor does not refer to a trans‐
                      port endpoint.


       TBADOPT        The specified protocol options were in an incorrect for‐
                      mat or contained illegal information.


       TBUFOVFLW      The  number  of bytes allocated for an incoming argument
                      (maxlen) is greater than 0 but not sufficient  to  store
                      the  value  of that argument. If executed in synchronous
                      mode, the provider's state, as seen by the user, changes
                      to  T_DATAXFER,  and  the  information to be returned in
                      rcvcall is discarded.


       TLOOK          An asynchronous event has  occurred  on  this  transport
                      endpoint and requires immediate attention.


       TNODATA        O_NONBLOCK  was set, so the function successfully initi‐
                      ated the connection establishment procedure, but did not
                      wait for a response from the remote user.


       TNOTSUPPORT    This  function is not supported by the underlying trans‐
                      port provider.


       TOUTSTATE      The communications endpoint referenced by fd is  not  in
                      one  of  the  states in which a call to this function is
                      valid.


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


       TSYSERR        A system error has occurred  during  execution  of  this
                      function.


TLI COMPATIBILITY
       The XTI and TLI interface definitions have common names but use differ‐
       ent header files. This, and other semantic differences between the  two
       interfaces are described in the subsections below.

   Interface Header
       The  XTI  interfaces  use the header file, xti.h. TLI interfaces should
       not use this header. They should use the header:

         #include <tiuser.h>


   Error Description Values
       The TPROTO and TADDRBUSY  t_errno values can be set by the  XTI  inter‐
       face but not by the TLI interface.


       A  t_errno  value  that this routine can return under different circum‐
       stances than its XTI counterpart is TBUFOVFLW. It can be returned  even
       when the maxlen field of the corresponding buffer has been set to zero.

   Option Buffers
       The format of the options in an opt buffer is dictated by the transport
       provider. Unlike the XTI interface, the TLI interface does not fix  the
       buffer format.

ATTRIBUTES
       See attributes(7) for descriptions of the following attributes:


       tab()  box; cw(2.75i) |cw(2.75i) lw(2.75i) |lw(2.75i) ATTRIBUTE TYPEAT‐
       TRIBUTE VALUE _ MT LevelSafe


SEE ALSO
       fcntl(2),  t_snddis(3C),  t_accept(3C),   t_alloc(3C),   t_getinfo(3C),
       t_listen(3C),      t_open(3C),     t_optmgmt(3C),     t_rcvconnect(3C),
       t_rcvdis(3C), attributes



Oracle Solaris 11.4               7 May 1998                     t_connect(3C)
맨 페이지 내용의 저작권은 맨 페이지 작성자에게 있습니다.
RSS ATOM XHTML 5 CSS3