Like I wrote, I am very much a fan of using either heap_4 or heap_5. They are very well optimised and heap_5 is initialised in a very dynamic way.
I just see that the socket option
FREERTOS_SO_REUSE_LISTEN_SOCKET was used. That is an option for advanced users, and must be well understood.
Imagine a telnet server that will only accept one client at a time. You create a server socket, bind it to port 23, and call
FreeRTOS_listen(). As soon as it gets connected, it turns the server socket into a client socket. The client socket will get the same address as the server socket:
client_socket = FreeRTOS_accept( server_socket );
if( xSocketValid( client_socket ) )
/* The server socket stops to exist and
* shall not be referred to any more */
server_socket = NULL;
FreeRTOS_accept() succeeds, the identifier
server_socket may not be used any more.
client_socket will be used to talk with the telnet client. As soon as that conversation is ready, the application must close ( delete ) the client socket:
FreeRTOS_closesocket( client_socket );
client_socket = NULL;
and create a new server socket.
It is also possible to create a normal server socket and limit the number of connected clients. In that case use the second parameter of
BaseType_t client_count = 3;
FreeRTOS_listen( server_socket, client_count );
This only works when the socket option
FREERTOS_SO_REUSE_LISTEN_SOCKET is not used.
Now 3 clients will manage to connect to the server. Number 4 will get a RST response to its attempt to connect.
As soon as one client disconnects, a new connect attempt will succeed.
This behaviour is slightly different from the backlog argument normally seen with
An embedded device has limited resources, and this feature will protect it against SYN attacks from outside: the library will reply with a RST packet, and no
pvPortMalloc() will be spilled.