When recv returns?

Question

I'm receiving data from Windows sockets over TCP protocol. For this purpose I'm using blocking recv().

My question is: when the operation system(OS) allows to read tcp buffer (from the tcp point of view)? Is it happens after the OS sends ACK on received data?

Answer 1

For all practical purposes you should view TCP receiving as composed of two independent processes:

• the OS receives the TCP data and ACKs it to the other side, storing it in an internal kernel buffer that's not accessible to your process
• when you recv or any equivalent system call, the OS copies the data from its internal buffers to your userspace buffer

Once TCP has received data that is in window and passes checksums and all, the other side cannot renege it. Which means it doesn't really matter if it sends the ACK before or after you read the data. Plus, the OS might need to ACK again (if the ACK is lost for example). Thus, the timing of ACKing data has nothing to do with you reading from the socket (the advertised window however, does).

The takeaway from this is that you doing recv has no effect on the connection. You can view recv as a fancy memcpy from the socket buffer to your application buffer.

Answer 2

From your application program you can call recv at any time. If the socket is blocking then recv will not return until there is some data present in the TCP internal receive buffer.

If the peer sends in some data the TCP stack shall take care of sending the ACK. Calling recv now results in data getting copied from the TCP stack's buffer to your buffer passed on to the 'recv`.

As noted by @cnicutar in another answer, even if you don't call recv TCP would have sent the ACK to keep the connection sane. Applications can call recv, get the data into their buffer which results in TCP's buffer getting flushed. Another recv won't give you the same data.