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
Attempting to send on the stale socket blocks, which is okay on its own. But I'm already using select() and observed that these stale sockets still somehow seem to block communication over new sockets, even when no stale sockets are included in the write set of select(). I even close() (successfully, according to the return value) those stale sockets after they failed to be write-ready after 10 seconds, but I can see in Wireshark that LWIP still sends retransmissions from the port number of the closed socket.
Could it be that close() cannot send FIN because the output buffer is full, so the socket still remains active? Is there a way from the API to just drop the connection without involving any more communication?
Daniel