On Wed, Oct 21, 2020 at 05:17:01PM +0100, Adam Hill wrote: > On Linux at least, you can see how much unsent data remains by querying the > SIOCOUTQ ioctl, so the mitigation would be to check to see that ANY data > was draining at all, and if so ( and there's some left ) extend the > lingering close time and repeat. However, this wouldn't be a cross platform > solution, but it would at least be the "correct" thing to do in terms of > network function. Not sure if there's an equivalent on other systems.
Nice writeup, thank you. Also discussed with similar conclusions here: https://bz.apache.org/bugzilla/show_bug.cgi?id=63666 and https://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-so_linger-page-or-why-is-my-tcp-not-reliable and a quite related writeup: https://blog.cloudflare.com/when-tcp-sockets-refuse-to-die/ which suggests using the Linux TCP_INFO socket option for getting information about how fast the send buffer is draining. I don't have much of substance to contribute... If it is not safe to implement a lingering close using a timeout on socket readability to detect EOF, it seems like it is impossible to implement a lingering close with a timeout using the BSD socket API, which seems rather shocking conclusion. So I kind of wish that something was missed here, but multiple people have come to exactly that conclusion independently. Regards, Joe
