Am I understanding the description correctly that sending on the stale connection eventually blocks once the remote side has crashed and this prevents sending on the new socket (only because the thread is blocked)?
If so, then the socket buffer on the stale socket has filled up (most likely) and is now blocking. This is blocking I/O operating as expected when data is not being acknowledged. You should use non-blocking sockets and select if your server is servicing multiple sockets on a single thread.
On Dec 23, 2016, at 04:15 PM, Daniel Pauli <address@hidden> wrote:
Hey there
I have a TCP client running on a Windows PC that communicates with a TCP
server on a LWIP box. The client sends requests to the server in high
frequency (polling) and receives responses of approx. 16 KB.
The problem: When a clients crashes (without being able to send FIN/RST
because of e.g. temporary link down) and gets restarted, the server is
unable to send responses over the new connection because send() blocks.
This happens even though I'm using select() to determine if sockets are
writable. I'm using a SO_SNDTIMEO of 3 seconds for tracking the problem
down. Strangely, send() already returns after 1 second with EWOULDBLOCK.
I observed that LWIP performs TCP retransmissions on the socket from the
crashed client. In my setting, these retransmissions are ignored by the
PC (due to the Windows firewall).
The problem resolves after approx 25 min when LWIP stops performing
these retransmissions. After that, send() works again for new connections.
Any hints are greatly appreciated :)
Regards
Daniel
_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users