RTEMS Network Supplement
RTEMS adds two new SOL_SOCKET level options for setsockopt and
getsockopt: SO_SNDWAKEUP and SO_RCVWAKEUP. For both, the
option value should point to a sockwakeup structure. The sockwakeup
structure has the following fields:
void (*sw_pfn) (struct socket *, caddr_t); caddr_t sw_arg;
These options are used to set a callback function to be called when, for
example, there is
data available from the socket (SO_RCVWAKEUP) and when there is space
available to accept data written to the socket (SO_SNDWAKEUP).
If setsockopt is called with the SO_RCVWAKEUP option, and the
sw_pfn field is not zero, then when there is data
available to be read from
the socket, the function pointed to by the sw_pfn field will be
called. A pointer to the socket structure will be passed as the first
argument to the function. The sw_arg field set by the
SO_RCVWAKEUP call will be passed as the second argument to the function.
If setsockopt is called with the SO_SNDWAKEUP
function, and the sw_pfn field is not zero, then when
there is space available to accept data written to the socket,
the function pointed to by the sw_pfn field
will be called. The arguments passed to the function will be as with
SO_SNDWAKEUP.
When the function is called, the network semaphore will be locked and the callback function runs in the context of the networking task. The function must be careful not to call any networking functions. It is OK to call an RTEMS function; for example, it is OK to send an RTEMS event.
The purpose of these callback functions is to permit a more efficient alternative to the select call when dealing with a large number of sockets.
The callbacks are called by the same criteria that the select function uses for indicating "ready" sockets. In Stevens Unix Network Programming on page 153-154 in the section "Under what Conditions Is a Descriptor Ready?" you will find the definitive list of conditions for readable and writable that also determine when the functions are called.
When the number of received bytes equals or exceeds the socket receive buffer "low water mark" (default 1 byte) you get a readable callback. If there are 100 bytes in the receive buffer and you only read 1, you will not immediately get another callback. However, you will get another callback after you read the remaining 99 bytes and at least 1 more byte arrives. Using a non-blocking socket you should probably read until it produces error EWOULDBLOCK and then allow the readable callback to tell you when more data has arrived. (Condition 1.a.)
For sending, when the socket is connected and the free space becomes at or above the "low water mark" for the send buffer (default 4096 bytes) you will receive a writable callback. You don't get continuous callbacks if you don't write anything. Using a non-blocking write socket, you can then call write until it returns a value less than the amount of data requested to be sent or it produces error EWOULDBLOCK (indicating buffer full and no longer writable). When this happens you can try the write again, but it is often better to go do other things and let the writable callback tell you when space is available to send again. You only get a writable callback when the free space transitions to above the "low water mark" and not every time you write to a non-full send buffer. (Condition 2.a.)
The remaining conditions enumerated by Stevens handle the fact that sockets become readable and/or writable when connects, disconnects and errors occur, not just when data is received or sent. For example, when a server "listening" socket becomes readable it indicates that a client has connected and accept can be called without blocking, not that network data was received (Condition 1.c).
RTEMS Network Supplement
Copyright © 1988-2007OAR Corporation