The remote kernel sees the connection fine. It accepts it, receives the data, the client closes its end. What might not happen is, in a very resource strained c

The remote kernel sees the connection fine. It accepts it, receives the data, the client closes its end. What might not happen is, in a very resource strained condition, is for the remote application to get the data. There's no relation between you doing a connect() and the remote doing an accept() in TCP, it's handled asynchronously by the kernel. (Traditionally the backlog argument to listen() controlled this behavior, but that backlog argument is by and large ignored on modern operating systems) The caveat here is that you close() the socket when you're done. close() does not, by default, wait until the remote end also closed its end. In the scenario described above, the remote end would eventually signal an error, but if you shoved the data into the remote kernel buffers, close and forget about that connection, your app will never see that error.