In my application, I have a need of opening and closing various sockets rather quick due to the limited number of sockets. This means I open a TCP connection to a server, send and recv some data, close the socket and do it over again. I never get an error when I close the socket, but I do get an error eventually about it not being able to send all the packets or in the case of the remote end dying without closing the connection.
In the SDK 1.1.0 and associated service pack, the CC3200 would attempt to make all the ACK and handshake packets go through for about 400ms (2 retry packets). This was manageable. However, in SDK 1.2.0 and its associated service pack, it seems the CC3200 has increased the amount of time to try and gracefully resolve the socket before closing from 400ms to 10 seconds. This has caused my application some grief as the socket is not released back into the pool of 8 available sockets until this 10 second timeout is reached. I can see in the call back function for the socket events 10 seconds later when the socket has been fully closed, but I cannot cope with this 10 seconds long delay.
What I would like to do is either change the time the CC3200 tries to gracefully close the TCP connection to a small value and in some cases set it to 0 (and cause the immediate transmission of the RST packet). This is very similar to the LINGER option in BSD sockets and it appears that the underlying TCP/IP stack supports dynamically changing this timeout value (as it has been changed from 400ms to 10sec between service packs).
Can this timeout value be exposed through the API to the user? Is it already exposed and I am just un-aware of it? Is there an API call I can call after sl_Close that will allow me to tell the NWP to abandon the socket and release its resources so I may open another socket?
Thanks.
