11 ms·
I always thought CLOSE_WAIT was due to unsent bytes after a close(). This definitely implies differently than my understanding, I'm surprised the article doesn'
by bluejekyll 10y ago
I always thought CLOSE_WAIT was due to unsent bytes after a close(). This definitely implies differently than my understanding, I'm surprised the article doesn't discuss SO_LINGER at all, from man pages:
>SO_LINGER controls the action taken when unsent messages are queued on
> socket and a close(2) is performed. If the socket promises reliable
> delivery of data and SO_LINGER is set, the system will block the process
> on the close attempt until it is able to transmit the data or until it
> decides it is unable to deliver the information (a timeout period, termed
> the linger interval, is specified in the setsockopt() call when SO_LINGER
> is requested). If SO_LINGER is disabled and a close is issued, the sys-
tem will process the close in a manner that allows the process to con-
> tinue as quickly as possible.
Am I wrong?
- majke 10y agoThis article describes a case when close() is _not_ being called in the first place. But indeed, it's very interesting what exactly the application can do after it receives FIN. I suspect it has 60 seconds tops to send any remaining data, and SO_LINGER could be useful there.