About the memory use of FreeRTOS +TCP
“Network Buffer Descriptors” are the objects that hold the network messages. They normally have a short life, after a few ms they are delivered to their destination.
The UDP protocol uses discrete messages. Therefore these message will stay in their ‘Network Buffer Descriptors’ while waiting to be picked up by
When TCP receives new data, the contents of the ‘Network Buffer Descriptors’ is copied to an RX stream buffer. Outgoing data (
) will be copied a the TX stream buffer.
The advantage is that if you send many small messages, they will end up into a single contiguous buffer, and sent-out in maximum-size packets (MSS).
So every connected TCP socket will get a TX and RX stream buffer. Once a stream buffer is created, its size is fixed.
The default stream buffer sizes are defined with:
/* Define the size of Rx buffer for TCP sockets. */
define ipconfigTCPRXBUF_LEN ( 3 * 1460 )
/* Define the size of Tx buffer for TCP sockets. */
define ipconfigTCPTXBUF_LEN ( 2 * 1460 )
But indeed they can be adjusted at runtime, see:
Probably the easiest way is to use is
. It will overwrite the above defaults in a single call.
Set the window properties before
a socket gets connected: the listening socket that will
a new connection, or a client socket that will
to a remote one.
Note that when
succeeds, all socket properties will be inherited by the new child socket, including stream buffer sizes (and also the local port number will be the same as its parent socket).
Using BufferAllocation 1 or 2 ?
Have you seen the difference between BufferAllocation1 and BufferAllocation
Both modules will provide this number of Network Buffer Descriptors:
#define ipconfigNUM_NETWORK_BUFFER_DESCRIPTORS ??
Version 1 is more efficient, it reserves all buffer space by calling the user-provided
right after start-up.
The advantage of version 1 is that all network buffer descriptors are guaranteed to be available and no more calls to
In version 2 only the Descriptors are allocated at start-up, and the actual Buffers will be malloc’d when needed. Small messages will use small buffers.
In general: platforms with more than enough (SD)RAM will use
About the backlog parameter in
Looking at http://linux.die.net/man/2/listen :
int listen(int sockfd, int backlog);
The official meaning of
is the following:
“The backlog argument defines the maximum length to which the queue of pending connections for sockfd may grow.”
FreeRTOS is typically running on a smaller system with less resources and the definition is slightly (only slightly) different:
“The backlog argument defines the maximum of connections that can be established to the socket simultaneously.”
It is important to let +TCP send keep-alive messages in an idle connection:
/* Include support for TCP keep-alive messages. */
#define ipconfigTCP_KEEP_ALIVE ( 1 )
#define ipconfigTCP_KEEP_ALIVE_INTERVAL ( 20 ) /* in seconds */
Otherwise a service might become unreachable because of ‘dead’ connections.
A TCP connection becomes dead if the remote device is switched off suddenly without properly closing the connection.
If keep-alive messages are being used, +TCP device will quickly detect that the remote end doesn’t respond any more.
An alternative to the above is it send keep-alive message at the user level. In a Telnet client for instance you could send empty lines (CR/LF) regularly to keep the remote end happy.
Enough text for now. I hope it clarifies things, and if not, please ask!