The SO_LINGER page, or: why is my TCP not reliable (2009)

This is what we used to call a &quot;Berkeleyism&quot;. It&#x27;s an error in the UC Berkeley implementation of TCP in the kernel, which, being free, became standard. (Yes, there was TCP&#x2F;IP before Berkeley UNIX, at least four implementations.)<p>The trouble is that UNIX does not take &quot;close()&quot; very seriously. This is because &quot;close()&quot; is implicit on exit, and having &quot;exit()&quot; stall waiting for I&#x2F;O is undesirable. So, close is non-blocking. When you close a file after writing, close happens immediately, even if writing is not yet done. &quot;Calling close() DOES NOT guarantee that contents are on the disk as the OS may have deferred the writes.&quot;<p>So sockets got the same unchecked semantics as files.<p>Now, logically, you&#x27;d call &quot;fsync()&quot; to get a socket fully flushed. But, another Berkeleyism is that sockets were originally distinct from the file system, because networking was bolted on as an afterthought and not well integrated. Hence &quot;send&quot; and &quot;recv&quot; instead of &quot;read&quot; and &quot;write&quot;. Being able to use read and write on sockets came later. So, sockets have &quot;shutdown&quot;.

<i>When the socket is closed as part of exit(2), it always lingers in the background</i><p>In other words, <i>not</i> closing the socket before exiting might actually be the easiest way to not have the connection aborted with pending data?<p>Note that Windows has slightly different, and perhaps the more expected, semantics for closing a socket with pending data:<p><a href="https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;windows&#x2F;win32&#x2F;api&#x2F;winsock&#x2F;nf-winsock-closesocket" rel="nofollow">https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;windows&#x2F;win32&#x2F;api&#x2F;winsock&#x2F;n...</a><p><i>However, any data queued for transmission will be sent, if possible, before the underlying socket is closed. This is also called a graceful disconnect or close. In this case, the Windows Sockets provider cannot release the socket and other resources for an arbitrary period, thus affecting applications that expect to use all available sockets. This is the default behavior for a socket.</i>