t_sndv man page on SunOS

Man page or keyword search:  
man Server   20652 pages
apropos Keyword Search (all sections)
Output format
SunOS logo
[printable version]

t_sndv(3NSL)	     Networking Services Library Functions	  t_sndv(3NSL)

NAME
       t_sndv  -  send data or expedited data, from one or more non-contiguous
       buffers, on a connection

SYNOPSIS
       #include <xti.h>

       int t_sndv(int fd, const struct t_iovec *iov,  unsigned	int  iovcount,
       int flags);

DESCRIPTION
       This  function  is  used	 to send either normal or expedited data.  The
       argument	 fd identifies the local transport endpoint  over  which  data
       should be sent,	iov points to an array of buffer address/buffer length
       pairs.	t_sndv() sends data contained  in  buffers   iov0  ,   iov1  ,
       through	iov [iovcount-1]. iovcount contains the number of non-contigu‐
       ous data buffers which is limited  to   T_IOV_MAX,  an  implementation-
       defined	value  of at least 16.	If the limit is exceeded, the function
       fails with TBADDATA.

       iov(0).iov_len + . . + iov(iovcount-1).iov_len)

       Note that the limit on the total number of bytes available in all  buf‐
       fers passed:

       may  be	constrained  by	 implementation limits. If no other constraint
       applies, it will be limited by INT_MAX. In practice,  the  availability
       of  memory  to  an application is likely to impose a lower limit on the
       amount of data that can be sent or received using scatter/gather	 func‐
       tions.

       The argument  flags specifies any optional flags described below:

       T_EXPEDITED     If  set	in  flags,  the data will be sent as expedited
		       data and will be subject to the interpretations of  the
		       transport provider.

       T_MORE	       If  set	in   flags,  this  indicates  to the transport
		       provider that the transport service  data  unit	(TSDU)
		       (or  expedited  transport service data unit - ETSDU) is
		       being sent through multiple
			t_sndv() calls. Each  t_sndv() with the	  T_MORE  flag
		       set  indicates  that  another  t_sndv() or  t_snd(3NSL)
		       will follow with more data for  the  current  TSDU  (or
		       ETSDU).

       The  end	 of the TSDU (or ETSDU) is identified by a  t_sndv() call with
       the  T_MORE flag not set.  Use of  T_MORE enables a user	 to  break  up
       large  logical  data units without losing the boundaries of those units
       at the other end of the connection.  The flag implies nothing about how
       the  data  is  packaged for transfer below the transport interface.  If
       the transport provider does not support the concept of a TSDU as	 indi‐
       cated  in  the	info  argument	on return from	t_open(3NSL) or t_get‐
       info(3NSL), the	T_MORE flag is not meaningful and will be  ignored  if
       set.

       The  sending  of a zero-length fragment of a TSDU or ETSDU is only per‐
       mitted where this is used to indicate the end of a TSDU or ETSDU,  that
       is,  when  the	T_MORE	flag is not set. Some transport providers also
       forbid zero-length TSDUs and ETSDUs.

       If set in flags, requests that the provider transmit all data  that  it
       has  accumulated	 but  not  sent.  The request is a local action on the
       provider and does not affect any similarly  named  protocol  flag  (for
       example, the TCP PUSH flag). This effect of setting this flag is proto‐
       col-dependent, and it may be ignored entirely  by  transport  providers
       which do not support the use of this feature.

       The  communications  provider  is free to collect data in a send buffer
       until it accumulates a sufficient amount for transmission.

       By default,  t_sndv() operates in synchronous mode and may wait if flow
       control	restrictions prevent the data from being accepted by the local
       transport provider at the time the call is made.	 However,  if	O_NON‐
       BLOCK is set by means of
	 t_open(3NSL)  or   fcntl(2),  t_sndv() executes in asynchronous mode,
       and will fail immediately if there are flow control restrictions.   The
       process	can  arrange to be informed when the flow control restrictions
       are cleared via either t_look(3NSL) or the EM interface.

       On  successful  completion,   t_sndv()  returns	the  number  of	 bytes
       accepted by the transport provider.  Normally this will equal the total
       number of bytes to be sent, that is,

       (iov0.iov_len + .. + iov[iovcount-1].iov_len)

       However, the interface is constrained to send at most  INT_MAX bytes in
       a  single  send.	  When	t_sndv() has submitted	INT_MAX (or lower con‐
       strained value, see the note above) bytes to the provider for a	single
       call,  this  value is returned to the user.   However, if O_NONBLOCK is
       set or the function is interrupted by a signal,	it  is	possible  that
       only  part of the data has actually been accepted by the communications
       provider.  In this case,	 t_sndv() returns a value that	is  less  than
       the  value of nbytes.  If t_sndv() is interrupted by a signal before it
       could transfer data to the communications provider, it returns  -1 with
       t_errno set to TSYSERR and  errno set to EINTR.

       If the number of bytes of data in the  iov array is zero and sending of
       zero octets is not  supported  by  the  underlying  transport  service,
       t_sndv() returns	 -1 with t_errno set to TBADDATA.

       The size of each TSDU or ETSDU must not exceed the limits of the trans‐
       port provider as specified by the current values in the TSDU  or	 ETSDU
       fields in the  info argument returned by t_getinfo(3NSL).

       The  error  TLOOK  is  returned for asynchronous events. It is required
       only for an incoming disconnect event but may  be  returned  for	 other
       events.

RETURN VALUES
       On  successful  completion,   t_sndv()  returns	the  number  of	 bytes
       accepted by the transport provider.   Otherwise,	  -1  is  returned  on
       failure and  t_errno is set to indicate the error.

       Note  that in synchronous mode, if more than  INT_MAX bytes of data are
       passed in the  iov array, only the first	 INT_MAX bytes will be	passed
       to the provider.

       If  the number of bytes accepted by the communications provider is less
       than the number of bytes	 requested,  this  may	either	indicate  that
       O_NONBLOCK  is  set  and	 the communications provider is blocked due to
       flow control, or that  O_NONBLOCK is clear and the function was	inter‐
       rupted by a signal.

VALID STATES
       T_DATAXFER, T_INREL.

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

       TBADDATA	       Illegal amount of data:

       TBADF	       The  specified  file  descriptor	 does  not  refer to a
		       transport endpoint.

			 ·  A single send  was	attempted  specifying  a  TSDU
			    (ETSDU) or fragment TSDU (ETSDU) greater than that
			    specified by the current values  of	 the  TSDU  or
			    ETSDU fields in the	 info argument.

			 ·  A  send  of	 a zero byte TSDU (ETSDU) or zero byte
			    fragment of a TSDU (ETSDU) is not supported by the
			    provider.

			 ·  Multiple  sends were attempted resulting in a TSDU
			    (ETSDU) larger than that specified by the  current
			    value  of  the  TSDU  or ETSDU fields in the  info
			    argument - the ability of an XTI implementation to
			    detect such an error case is implementation-depen‐
			    dent.  See WARNINGS, below.

			 ·  iovcount is greater than  T_IOV_MAX.

       TBADFLAG	       An invalid flag was specified.

       TFLOW	       O_NONBLOCK was set, but the flow control mechanism pre‐
		       vented  the  transport provider from accepting any data
		       at this time.

       TLOOK	       An asynchronous event has occurred  on  this  transport
		       endpoint.

       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
       In the TLI interface definition, no counterpart	of  this  routine  was
       defined.

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

       ┌─────────────────────────────┬─────────────────────────────┐
       │      ATTRIBUTE TYPE	     │	    ATTRIBUTE VALUE	   │
       ├─────────────────────────────┼─────────────────────────────┤
       │MT Level		     │Safe			   │
       └─────────────────────────────┴─────────────────────────────┘

SEE ALSO
       t_getinfo(3NSL),	 t_open(3NSL),	t_rcvv(3NSL) t_rcv(3NSL), t_snd(3NSL),
       attributes(5)

WARNINGS
       It is important to remember that	 the  transport	 provider  treats  all
       users  of  a  transport endpoint as a single user. Therefore if several
       processes issue concurrent  t_sndv() or	t_snd(3NSL)  calls,  then  the
       different data may be intermixed.

       Multiple	 sends	which exceed the maximum TSDU or ETSDU size may not be
       discovered by XTI.  In this case an implementation-dependent error will
       result  (generated  by the transport provider), perhaps on a subsequent
       XTI call.  This error may take the form of a connection abort,  a  TSY‐
       SERR, a TBADDATA or a TPROTO error.

       If  multiple  sends  which  exceed  the	maximum TSDU or ETSDU size are
       detected by XTI,	 t_sndv() fails with TBADDATA.

SunOS 5.10			  23 Aug 2001			  t_sndv(3NSL)
[top]

List of man pages available for SunOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net