16

Let's say we have the following TCP socket setup where client sends arbitary data to the server. Treat the following as a pseudocode.

    def client():
        while True:
            data = source.get_data()
            client_socket.send(data)

The server reads the data and uses it to do something...

    def server():
        while True:
            data += socket.recv(4096)
            parsed_data = parse_data(data)  
            cpu_intensive_task(parsed_data)

Let's assume that client will send the data much faster than the server can process. Can the internal network buffer fill up? I assume the answer is yes...

If so, then does the TCP protocol specify what will happend in this scenario? Are these discared packets treated as if they were lost in transit and just re-transmitted like any other lost packages?

Or are these packets truly lost and this something I have to consider when desiging my own communication protocol on top of the TCP?

Does the answer vary between operating systems?

For a record, the system above should have some kind of congestion control mechanism, which server could use to tell the client that it's under heavy load or it's free again. However, I'm curious to know how the TCP by the default would behave in this scenario.

rkrzr
  • 1,842
  • 20
  • 31
TukeV
  • 641
  • 2
  • 6
  • 13

1 Answers1

19

Can the internal network buffer fill up?

There are two internal buffers: the send buffer and the receive buffer. Both can fill up.

I assume the answer is yes...

Yes.

If so, then does the TCP protocol specify what will happen in this scenario?

Yes.

Are these discarded packets

There are no discarded packets. TCP does not discard packets in this circumstance. What happens when the send buffer fills depends on whether you are in blocking or non-blocking mode, or whether you are using an asynchronous API:

  • blocking mode: the sender blocks
  • non-blocking mode: the sender gets an error EAGAIN/EWOULDBLOCK
  • asynchronous: the operation continues to be deferred.

treated as if they were lost in transit and just re-transmitted like any other lost packages?

No. See above.

Or are these packets truly lost

No. See above.

and this something I have to consider when desiging my own communication protocol on top of the TCP?

No. See above. But the various conditions are certainly something you have to consider in your implementation of the protocol.

Does the answer vary between operating systems?

No.

For a record, the system above should have some kind of congestion control mechanism

TCP already has a congestion control mechanism.

which server could use to tell the client that it's under heavy load

How? if the client isn't reading, how can the server tell it anything?

or it's free again. However, I'm curious to know how the TCP by the default would behave in this scenario.

See above.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • Thanks for the answer. The thing about telling the client if the server is under heavy load, naturally that would mean that server would have a send call where it sends the required message to the client and the client should have a line where it reads this said message and acts accordingly. I just wanted to keep the example as short and simple as possible to illustrate the question and leave unnecessary details out. – TukeV Apr 04 '18 at 11:17
  • 2
    But if the server can't send to the client because its send buffer is full, the server cant sendt to the client, because its send buffer is full. The only way out of this is a client read timeout. – user207421 Apr 04 '18 at 12:27
  • Ok, I think I misunderstood what you meant by client not reading and server not telling. By congestion control I was thinking about more holisitc approach and trying to prevent whole situation to happening in the first place. – TukeV Apr 04 '18 at 13:12
  • @TukeV Why? TCP already handles it properly. All you will accomplish by trying to avoid it is lower throughput. – user207421 Jun 04 '21 at 07:06
  • This answer doesn't answer what happens server read buffer becomes full, is it guaranteed that the following data sent is not dropped as part of tcp layer? – rjhcnf Apr 27 '23 at 19:53