4 ms·
I still don't get how this can happen as described. If the client is using a blocking connect and checking for errors (as the author says it is), I don't see h
by dap 13y ago
I still don't get how this can happen as described. If the client is using a blocking connect and checking for errors (as the author says it is), I don't see how that can succeed without the remote side at least seeing the connection. As you say, the receiver could be overloaded and ignore the connection, but the client should get a connect failure in that case.
- noselasd 13y agoThe 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.