socklib.html

vxworks相关论文

<a name="send"></a>
<p align=right>
<a href="rtnIndex.html"><i>Libraries :  Routines</i></a></p>

</blockquote><h1><i>send</i>(&nbsp;)</h1> <blockquote></a></blockquote><h4>NAME</h4><blockquote>  
<p><strong><i>send</i>(&nbsp;)</strong> - send data to a socket</p>

</blockquote><h4>SYNOPSIS</h4><blockquote><p>
<pre>int send
    (
    int    s,      /* socket to send to */
    char * buf,    /* pointer to buffer to transmit */
    int    bufLen, /* length of buffer */
    int    flags   /* flags to underlying protocols */
    )</pre>

</blockquote><h4>DESCRIPTION</h4><blockquote><p>
This routine transmits data to a previously established connection-based
(stream) socket.
<p>
The maximum length of <i>buf</i> is subject to the limits
on TCP buffer size; see the discussion of <b>SO_SNDBUF</b> in the
<b><i><a href="./sockLib.html#setsockopt">setsockopt</a></i>(&nbsp;)</b> manual entry.
<p>
You may OR the following values into the <i>flags</i> parameter with this
operation:
<p>
<dl>
<dt>
<b>MSG_OOB</b> (0x1)
<dd>

Out-of-band data.
<p>

<dt>
<b>MSG_DONTROUTE</b> (0x4)
<dd>
 Send without using routing tables. 
</dl>

<p>

</blockquote><h4>RETURNS</h4><blockquote><p>
The number of bytes sent, or ERROR if the call fails.
<p>
</blockquote><h4>SEE ALSO</h4><blockquote><p>
<b><a href="./sockLib.html#top">sockLib</a></b>, <b><i><a href="./sockLib.html#setsockopt">setsockopt</a></i>(&nbsp;)</b>, <b><i><a href="./sockLib.html#sendmsg">sendmsg</a></i>(&nbsp;)</b>

<hr>
<a name="sendmsg"></a>
<p align=right>
<a href="rtnIndex.html"><i>Libraries :  Routines</i></a></p>

</blockquote><h1><i>sendmsg</i>(&nbsp;)</h1> <blockquote></a></blockquote><h4>NAME</h4><blockquote>  
<p><strong><i>sendmsg</i>(&nbsp;)</strong> - send a message to a socket</p>

</blockquote><h4>SYNOPSIS</h4><blockquote><p>
<pre>int sendmsg
    (
    int             sd,   /* socket to send to */
    struct msghdr * mp,   /* scatter-gather message header */
    int             flags /* flags to underlying protocols */
    )</pre>

</blockquote><h4>DESCRIPTION</h4><blockquote><p>
This routine sends a message to a datagram socket.  It may be used in
place of <b><i><a href="./sockLib.html#sendto">sendto</a></i>(&nbsp;)</b> to decrease the overhead of reconstructing the
message-header structure (<b>msghdr</b>) for each message.
<p>
For BSD 4.4 sockets a copy of the <i>mp</i>->msg_iov array will be made.  This
requires a cluster from the network stack system pool of size 
<i>mp</i>->msg_iovlen * sizeof (struct iovec) or 8 bytes.
<p>
</blockquote><h4>RETURNS</h4><blockquote><p>
The number of bytes sent, or ERROR if the call fails.
<p>
</blockquote><h4>SEE ALSO</h4><blockquote><p>
<b><a href="./sockLib.html#top">sockLib</a></b>, <b><i><a href="./sockLib.html#sendto">sendto</a></i>(&nbsp;)</b>

<hr>
<a name="recvfrom"></a>
<p align=right>
<a href="rtnIndex.html"><i>Libraries :  Routines</i></a></p>

</blockquote><h1><i>recvfrom</i>(&nbsp;)</h1> <blockquote></a></blockquote><h4>NAME</h4><blockquote>  
<p><strong><i>recvfrom</i>(&nbsp;)</strong> - receive a message from a socket</p>

</blockquote><h4>SYNOPSIS</h4><blockquote><p>
<pre>int recvfrom
    (
    int               s,       /* socket to receive from */
    char *            buf,     /* pointer to data buffer */
    int               bufLen,  /* length of buffer */
    int               flags,   /* flags to underlying protocols */
    struct sockaddr * from,    /* where to copy sender's addr */
    int *             pFromLen /* value/result length of <i>from</i> */
    )</pre>

</blockquote><h4>DESCRIPTION</h4><blockquote><p>
This routine receives a message from a datagram socket regardless of
whether it is connected.  If <i>from</i> is non-zero, the address of the
sender's socket is copied to it.  The value-result parameter <i>pFromLen</i>
should be initialized to the size of the <i>from</i> buffer.  On return,
<i>pFromLen</i> contains the actual size of the address stored in <i>from</i>.
<p>
The maximum length of <i>buf</i> is subject to the limits on UDP buffer
size; see the discussion of <b>SO_RCVBUF</b> in the <b><i><a href="./sockLib.html#setsockopt">setsockopt</a></i>(&nbsp;)</b> manual
entry.
<p>
You may OR the following values into the <i>flags</i> parameter with this
operation:
<p>
<dl>
<dt>
<b>MSG_OOB</b> (0x1)
<dd>

Out-of-band data.
<p>

<dt>
<b>MSG_PEEK</b> (0x2)
<dd>
 Return data without removing it from socket. 
</dl>

<p>

</blockquote><h4>RETURNS</h4><blockquote><p>
The number of number of bytes received, or ERROR if the call fails.
<p>
</blockquote><h4>SEE ALSO</h4><blockquote><p>
<b><a href="./sockLib.html#top">sockLib</a></b>, <b><i><a href="./sockLib.html#setsockopt">setsockopt</a></i>(&nbsp;)</b>

<hr>
<a name="recv"></a>
<p align=right>
<a href="rtnIndex.html"><i>Libraries :  Routines</i></a></p>

</blockquote><h1><i>recv</i>(&nbsp;)</h1> <blockquote></a></blockquote><h4>NAME</h4><blockquote>  
<p><strong><i>recv</i>(&nbsp;)</strong> - receive data from a socket</p>

</blockquote><h4>SYNOPSIS</h4><blockquote><p>
<pre>int recv
    (
    int    s,      /* socket to receive data from */
    char * buf,    /* buffer to write data to */
    int    bufLen, /* length of buffer */
    int    flags   /* flags to underlying protocols */
    )</pre>

</blockquote><h4>DESCRIPTION</h4><blockquote><p>
This routine receives data from a connection-based (stream) socket.
<p>
The maximum length of <i>buf</i> is subject to the limits on TCP buffer
size; see the discussion of <b>SO_RCVBUF</b> in the <b><i><a href="./sockLib.html#setsockopt">setsockopt</a></i>(&nbsp;)</b> manual
entry.
<p>
You may OR the following values into the <i>flags</i> parameter with this
operation:
<p>
<dl>
<dt>
<b>MSG_OOB</b> (0x1)
<dd>

Out-of-band data.
<p>

<dt>
<b>MSG_PEEK</b> (0x2)
<dd>
 Return data without removing it from socket. 
</dl>

<p>

</blockquote><h4>RETURNS</h4><blockquote><p>
The number of bytes received, or ERROR if the call fails.
<p>
</blockquote><h4>SEE ALSO</h4><blockquote><p>
<b><a href="./sockLib.html#top">sockLib</a></b>, <b><i><a href="./sockLib.html#setsockopt">setsockopt</a></i>(&nbsp;)</b>

<hr>
<a name="recvmsg"></a>
<p align=right>
<a href="rtnIndex.html"><i>Libraries :  Routines</i></a></p>

</blockquote><h1><i>recvmsg</i>(&nbsp;)</h1> <blockquote></a></blockquote><h4>NAME</h4><blockquote>  
<p><strong><i>recvmsg</i>(&nbsp;)</strong> - receive a message from a socket</p>

</blockquote><h4>SYNOPSIS</h4><blockquote><p>
<pre>int recvmsg
    (
    int             sd,   /* socket to receive from */
    struct msghdr * mp,   /* scatter-gather message header */
    int             flags /* flags to underlying protocols */
    )</pre>

</blockquote><h4>DESCRIPTION</h4><blockquote><p>
This routine receives a message from a datagram socket.  It may be used in
place of <b><i><a href="./sockLib.html#recvfrom">recvfrom</a></i>(&nbsp;)</b> to decrease the overhead of breaking down the
message-header structure <b>msghdr</b> for each message.
<p>
For BSD 4.4 sockets a copy of the <i>mp</i>->msg_iov array will be made.  This
requires a cluster from the network stack system pool of size 
<i>mp</i>->msg_iovlen * sizeof (struct iovec) or 8 bytes. 
<p>
</blockquote><h4>RETURNS</h4><blockquote><p>
The number of bytes received, or ERROR if the call fails.
</blockquote><h4>SEE ALSO</h4><blockquote><p>
<b><a href="./sockLib.html#top">sockLib</a></b>

<hr>
<a name="setsockopt"></a>
<p align=right>
<a href="rtnIndex.html"><i>Libraries :  Routines</i></a></p>

</blockquote><h1><i>setsockopt</i>(&nbsp;)</h1> <blockquote></a></blockquote><h4>NAME</h4><blockquote>  
<p><strong><i>setsockopt</i>(&nbsp;)</strong> - set socket options</p>

</blockquote><h4>SYNOPSIS</h4><blockquote><p>
<pre>STATUS setsockopt
    (
    int    s,       /* target socket */
    int    level,   /* protocol level of option */
    int    optname, /* option name */
    char * optval,  /* pointer to option value */
    int    optlen   /* option length */
    )</pre>

</blockquote><h4>DESCRIPTION</h4><blockquote><p>
This routine sets the options associated with a socket.
To manipulate options at the "socket" level, <i>level</i> should be <b>SOL_SOCKET</b>.
Any other levels should use the appropriate protocol number.
<p>
</blockquote><h4>OPTIONS FOR STREAM SOCKETS</h4><blockquote><p>
The following sections discuss the socket options available for
stream (TCP) sockets.
<p>
</blockQuote><h4>SO_KEEPALIVE -- Detecting a Dead Connection</h4><blockQuote>
Specify the <b>SO_KEEPALIVE</b> option to make the transport protocol (TCP)
initiate a timer to detect a dead connection:
<pre>    setsockopt (sock, SOL_SOCKET, SO_KEEPALIVE, &amp;optval, sizeof (optval));
</pre>
This prevents an application from  hanging on an invalid connection.
The value at <i>optval</i> for this option is an integer (type <b>int</b>),
either 1 (on) or 0 (off).
<p>
The integrity of a connection is verified by transmitting
zero-length TCP segments triggered by a timer, to force a response
from a peer node.  If the peer does not respond after repeated
transmissions of the KEEPALIVE segments, the connection is dropped,
all protocol data structures are reclaimed, and processes sleeping
on the connection are awakened with an ETIMEDOUT error.
<p>
The ETIMEDOUT timeout can happen in two ways.  If the connection is
not yet established, the KEEPALIVE timer expires after idling
for <b>TCPTV_KEEP_INIT</b>.  If the connection is established, the
KEEPALIVE timer starts up when there is no traffic for
<b>TCPTV_KEEP_IDLE</b>.  If no response is received from the peer after
sending the KEEPALIVE segment <b>TCPTV_KEEPCNT</b> times with interval
<b>TCPTV_KEEPINTVL</b>, TCP assumes that the connection is invalid.
The parameters <b>TCPTV_KEEP_INIT</b>, <b>TCPTV_KEEP_IDLE</b>, <b>TCPTV_KEEPCNT</b>, and
<b>TCPTV_KEEPINTVL</b> are defined in the file <b>target/h/net/tcp_timer.h</b>.
<p>
</blockQuote><h4>SO_LINGER -- Closing a Connection</h4><blockQuote>
Specify the <b>SO_LINGER</b> option to determine whether TCP should perform a
"graceful" close:
<pre>    setsockopt (sock, SOL_SOCKET, SO_LINGER, &amp;optval, sizeof (optval));
</pre>
For a "graceful" close in response to the shutdown of a connection, TCP 
tries to make sure that all the unacknowledged data in transmission channel
are acknowledged, and the peer is shut down properly, by going through an
elaborate set of state transitions.
<p>
The value at <i>optval</i> indicates the amount of time to linger if
there is unacknowledged data, using <b>struct linger</b> in
<b>target/h/sys/socket.h</b>.  The <b>linger</b> structure has two members:
<b>l_onoff</b> and <b>l_linger</b>.  <b>l_onoff</b> can be set to 1 to turn on the
<b>SO_LINGER</b> option, or set to 0 to turn off the <b>SO_LINGER</b> option.
<b>l_linger</b> indicates the amount of time to linger.  If <b>l_onoff</b> is
turned on and <b>l_linger</b> is set to 0, a default value <b>TCP_LINGERTIME</b>
(specified in <b>netinet/tcp_timer.h</b>) is used for incoming
connections accepted on the socket.
<p>
When <b>SO_LINGER</b> is turned on and the <b>l_linger</b> field is set to 0,
TCP simply drops the connection by sending out an RST if a
connection is already established; frees up the space for the TCP
protocol control block; and wakes up all tasks sleeping on the
socket.
<p>
For the client side socket, the value of <b>l_linger</b> is not changed
if it is set to 0.  To make sure that the value of <b>l_linger</b> is 0
on a newly accepted socket connection, issue another <b><i><a href="./sockLib.html#setsockopt">setsockopt</a></i>(&nbsp;)</b>
after the <b><i><a href="./sockLib.html#accept">accept</a></i>(&nbsp;)</b> call.
<p>
Currently the exact value of <b>l_linger</b> time is actually ignored
(other than checking for 0); that is, TCP performs the state
transitions if <b>l_linger</b> is not 0, but does not explicitly use its
value.
<p>
</blockQuote><h4>TCP_NODELAY -- Delivering Messages Immediately</h4><blockQuote>
Specify the <b>TCP_NODELAY</b> option for real-time protocols, such as the X
Window System Protocol, that require immediate delivery of many small
messages:
<pre>setsockopt (sock, IPPROTO_TCP, TCP_NODELAY, &amp;optval, sizeof (optval));
</pre>
The value at <i>optval</i> is an integer (type <b>int</b>) set to either 1
(on) or 0 (off).
<p>
By default, the VxWorks TCP implementation employs an algorithm that
attempts to avoid the congestion that can be produced by a large number
of small TCP segments. This typically arises with virtual terminal
applications (such as telnet or rlogin) across networks that have
low bandwidth and long delays.  The algorithm attempts to have no
more than one outstanding unacknowledged segment in the transmission
channel while queueing up the rest of the smaller segments for later
transmission.  Another segment is sent only if enough new data is
available to make up a maximum sized segment, or if the outstanding
data is acknowledged.
<p>
This congestion-avoidance algorithm works well for virtual terminal
protocols and bulk data transfer protocols such as FTP without any
noticeable side effects.  However, real-time protocols that require
immediate delivery of many small messages, such as the X Window
System Protocol, need to defeat this facility to guarantee proper
responsiveness in their operation.
<p>
<b>TCP_NODELAY</b> is a mechanism to turn off the use of this algorithm.
If this option is turned on and there is data to be sent out, TCP
bypasses the congestion-avoidance algorithm: any available data
segments are sent out if there is enough space in the send window.
<p>
</blockQuote><h4>SO_DEBUG -- Debugging the  underlying protocol</h4><blockQuote>
Specify the <b>SO_DEBUG</b> option to let the underlying protocol module record
debug information.
<pre>    setsockopt (sock, SOL_SOCKET, SO_KEEPALIVE, &amp;optval, sizeof (optval));
</pre>
The value at <i>optval</i> for this option is an integer (type <b>int</b>),
either 1 (on) or 0 (off).