by bluestreak on 6/12/21, 12:49 PM with 8 comments
by Animats on 6/12/21, 5:32 PM
The trouble is that UNIX does not take "close()" very seriously. This is because "close()" is implicit on exit, and having "exit()" stall waiting for I/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. "Calling close() DOES NOT guarantee that contents are on the disk as the OS may have deferred the writes."
So sockets got the same unchecked semantics as files.
Now, logically, you'd call "fsync()" 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 "send" and "recv" instead of "read" and "write". Being able to use read and write on sockets came later. So, sockets have "shutdown".
by userbinator on 6/12/21, 9:00 PM
In other words, not closing the socket before exiting might actually be the easiest way to not have the connection aborted with pending data?
Note that Windows has slightly different, and perhaps the more expected, semantics for closing a socket with pending data:
https://docs.microsoft.com/en-us/windows/win32/api/winsock/n...
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.