t_sndv - Receive data or expedited data sent over a connection
and put the data into one or more non-contiguous
const struct t_iovec *iov,
unsigned int iovcount,
int *flags );
XTI Library (libxti.a)
Interfaces documented on this reference page conform to
industry standards as follows:
Refer to the standards(5) reference page for more information
about industry standards and associated tags.
The following table summarizes the relevance of input and
output parameters before and after t_sndv() is called:
Parameters Before Call After Call
fd y n
iov y n
iovcount y n
iov.iov_base y(y) e(e)
iov.iov_len y e
iov[iov- y(y) e(e)
iov[iovcount-1].iov_len y e
flags y n
Notes to Table: This is a meaningful parameter. The content
of the object pointed to by y is meaningful. This is
a meaningful but optional parameter. The content of the
object pointed to by o is meaningful. The parameter value
after the call is the same as before the call. The content
of the object pointed to by e after the call is the
same as before the call. This is not a meaningful parameter.
Identifies the local transport endpoint over which
to send data. Points to an array of buffer address/buffer
size pairs (iov_base, iov_len). Specifies the number of
buffers, which is limited to T_IOV_MAX (an implementationdefined
value of at least 16). If the limit is exceeded,
the function will fail with [TBADDATA]. Specifies on of
the following flags options: If set, the data will be sent
as expedited data and will be subject to the interpretations
of the transport provider. If set, 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.
The t_sndv() function sends data either normal or expedited
data. The data is contained in buffers iov,
iov, through iov[iovcount-1].
The limit on the total number of bytes available in all
buffers passed (that is, iov(0).iov_len + ... + iov(iovcount-1).iov_len)
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
Each t_sndv() with the T_MORE flag set indicates that
another t_sndv() (or t_snd()) 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 the T_MORE flag 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 indicated in the info argument on
return from t_open() or t_getinfo(), 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 permitted
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 flags (for example, the TCP PUSH
flag). This effect of setting this flag is protocoldependent,
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
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_NONBLOCK is set (via
t_open() or fcntl()), 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() or the EM interface.
On successful completion, t_sndv() returns the number of
bytes accepted by the transport provider. Normally this
equals the total number of bytes to be sent, according to
the following formula:
iov.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 constrained value, see the previous
note) 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 transport provider as specified by the current values
in the TSDU or ETSDU fields in the info argument
returned by t_getinfo().
The [TLOOK] error is returned for asynchronous events. It
is required only for an incoming disconnect event, but may
be returned for other events.
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() calls, the
different data may be intermixed.
Multiple sends that 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
[TSYSERR], a [TBADDATA], or a [TPROTO] error.
If multiple sends that exceed the maximum TSDU or ETSDU
size are detected by XTI, t_sndv() fails with [TBADDATA].
If the t_sndv() function fails, t_errno may be set to one
of the following values: Illegal amount of data. Possible
reasons include: An attempt to send once, 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. An attempt to send zero-byte
TSDU (ETSDU) or zero-byte fragment of a TSDU (ETSDU) is
not supported by the provider. An attempt to send multiple
times, 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-dependent.
The iovcount parameter is greater than T_IOV_MAX.
File descriptor (fd) is not a valid transport endpoint.
An invalid option was specified. O_NONBLOCK was set, but
the flow control mechanism prevented the transport
provider from accepting the function. An asynchronous
event occurred on this transport endpoint and requires
immediate attention. This function is not supported by
the underlying transport provider. The communications
endpoint referenced by fd is not in a valid state in which
a call to this function. A communication problem has been
detected between XTI and the transport provider for which
there is no other suitable XTI error (t_errno). A system
error occurred during execution of this function.
The t_sndv() function can be called in either the
T_DATAXFER or T_INREL transport provider states.
Upon successful completion, t_sndv() returns a value of 0
(zero). Otherwise, it returns a value of -1 and sets
t_errno to indicate the error.
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 interrupted by a
Functions: t_getinfo(3), t_open(3), t_rcv(3), t_rcvv(3),
Network Programmer's Guide
[ Back ]