4 ms·
> For the reasons I mentioned, as long as the socket is open in the application on host B, I don't think the kernel can conclude that the program is done with i
by majke 10y ago
> For the reasons I mentioned, as long as the socket is open in the application on host B, I don't think the kernel can conclude that the program is done with it.
Wow. Awesome explanation. Ok, so basically as long as socket is in CLOSE-WAIT the server may want to send() something.
Do you happen to know what are the detailed semantics of `tcp_fin_timeout` sysctl? Will FIN-WAIT-2 progress to cleanup after 60 seconds, or after 60 seconds since last received packet?
Would this be sane:
- Let's allow kernel to expire CLOSE-WAIT if the application didn't send anything for more than 60 seconds.
- toast0 10y ago> Would this be sane: > - Let's allow kernel to expire CLOSE-WAIT if the application didn't send anything for more than 60 seconds. No, that's not sane either. If the application wants to expire the CLOSE_WAIT socket, it can close it; at which point, a FIN will be sent, the state will go to LAST_ACK, while waiting for the peer to ACK the FIN, at which point the socket is totally done. It violates the RFC, but is perfectly reasonable for LAST_ACK to have a timeout if the other peer is non-responsive, as the alternative is sockets living forever when the peer goes away (same with FIN_WAIT's).