tcp - close() socket directly after send(): unsafe?

Question

Is it wise/safe to close() a socket directly after the last send()?

I know that TCP is supposed to try to deliver all remaining data in the send buffer even after closing the socket, but can I really count on that?

I'm making sure that there is no remaining data in my receive buffer so that no RST will be sent following my close.

---

In my case, the close is actually the very last statement of code before calling exit().

Will the TCP stack really continue to try and transmit the data even after the process sending it has terminated? Is that as reliable as waiting for an arbitrary timeout myself before calling close() by setting SO_LINGER?

That is, do the same TCP timeouts apply, or are they shorter? With a big send buffer and a slow connection, the time to actually transfer all the buffered data could be substantial, after all.

---

I'm not interested at all in being notified of the last byte sent; I just want them to eventually arrive at the remote host as reliably as possible.

Application layer acknowledgements are not an option (the protocol is HTTP, and I'm writing a small server).

Answer 1

I've been reading the The ultimate SO_LINGER page, or: why is my tcp not reliable blog post a lot. I recommend you read it too. It discusses edge cases of large data transfers with regards to TCP sockets.

I'm not the expert at SO_LINGER, but on my server code (still in active development) I do the following:

1. After the last byte is sent via send(), I call shutdown(sock, SHUT_WR) to trigger a FIN to be sent.

2. Then wait for a subsequent recv() call on that socket to return 0 (or recv returns -1 and errno is anything other that EAGAIN/EWOULDBLOCK).

3. Then the server does a close() on the socket.

The assumption is that the client will close his socket first after it has received all the bytes of the response.

But I do have a timeout enforced between the final send() and when recv() indicates EOF. If the client never closes his end of the connection, the server will give up waiting and close the connection anyway. I'm at 45-90 seconds for this timeout.

All of my sockets are non-blocking and I use poll/epoll to be notified of connection events as a hint to see if it's time to try calling recv() or send() again.