What happens if POSIX does not call recv fast enough?

Question

I want to explain a possible scenario where clients of my TCP / IP streaming socket service send data to my service faster than it manages to move data to its buffers (I'm talking about application buffers, of course) using recv and work with it.

In general, what happens in such scenarios?

Obviously, some kind of service under my service, which is a user application, must accept the incoming stream and save it somewhere until I issue 'recv', right? Most likely an operating system.

I don’t want to rediscover old questions, but I can’t find the answer to this seemingly obvious question?

Answer 1

TCP provides flow control . The TCP stack (both on the sender side and on the receiver side) will be able to buffer some data for you, and this is usually done in the kernel of the OS.

When the receiver’s buffers are full, the sender will find out about it and stop sending more data, which will ultimately block the sending application (or, otherwise, will not be able to send more data) until the space becomes available again.

In a brief description, each TCP packet sent (segment) includes the size of the data that can be buffered — the size of the window. This means that the other end always knows how much data it can send if the receiver does not throw it away because the buffers are full. If the window size becomes 0, the buffers fill up and data will no longer be sent (and if the sender is blocked, the send() call is blocked), theres a procedure to check if the tcp 0 window remains, so sending can resume again when the data has been used .

Here are some more details here.

Answer 2

This is a network driver stack that supports data buffers (including for incoming data). If the buffer is full, subsequent TCP packets are discarded and the client gets stuck trying to send data. Here a little more here and here .