Sockets Programming Interfaces
3-12
3.3
Sockets Programming Interfaces
3.3.1
Synopsis
The socket function API supported by the stack library is consistent with the
standard Berkeley sockets API. No parameter adjustments are required.
In the interest of brevity, two new types are defined for the socket function dec-
larations:
typedef struct sockaddr SA;
typedef struct sockaddr *PSA;
3.3.2
Enhanced “No-Copy” Socket Operation
Any performance of any data stream operation suffers when data copies are
performed. Although the stack software is designed to use a minimum number
of data copies, memory efficiency and API compatibility sometimes require the
use of data copy operations.
By default, neither UDP nor RAW sockets use send or receive buffers. Howev-
er, the sockets API functions recv() and recvfrom() require a data buffer copy
because of how the calling parameters to the functions are defined. In the
stack library, two alternative functions (recvnc() and recvncfrom()) are pro-
vided to allow an application to get received data buffers directly without a copy
operation. When the application is finished with these buffers, it returns them
to the system via a call to recvncfree().
By default, TCP uses both a send and receive buffer. The send buffer is used
since the TCP protocol can require “reshaping” or retransmission of data due
to window sizes, lost packets, etc.. On receive, the standard TCP socket also
has a receive buffer. This is used to coalesce TCP data received from packet
buffers. Coalescing data is important for protocols that transmit data in very
small bursts (like a telnet session).
For TCP applications that get data in large bursts (and tend not to use flags
like MSG_WAITALL on receive), the receive buffer can be eliminated by speci-
fying an alternate TCP stream type of SOCK_STREAMNC (see page 2-8).
Without the receive buffer, there is at least one less data copy since TCP will
queue up the actual network packets containing receive data instead of copy-
ing it into a receive buffer.
Care needs to be taken when eliminating the TCP receive buffer. Here large
amounts of packet buffers can be tied up for a very small amount of data. Also,
since packet buffers come from the HAL, there may be a very limited supply
available. If the MSG_WAITALL flag is used on a recv() or recvfrom() call, it
is possible for all packet buffers to be consumed before the specified amount
of payload data is received. This would cause a deadlock situation if no socket
timeout is specified.