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. Joel On Dec 23, 2016, at 04:15 PM, Daniel Pauli <[email protected]> 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 [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
