CODEWITHSUNDEEP
tcpudpsliding-window
jellybean
jellybean

Reputation: 5

UDP TCP management of server congestion

Does TCP and UDP protocol have a way to manage their saturation?

When I write saturation, I mean Network congestion: what happens if the buffer of the server is full and the client sends a datagram UDP/TCP to the server?

Have these protocols a way to handle this scenario, or data would be lost?

Upvotes: 0

Views: 280

Answers (1)

Roberto Caboni
Roberto Caboni

Reputation: 7490

This is a question about TCP/UDP basics. For this reason this answer is not going to be a complete TCP and UDP guide.

Network congestion at low level protocols

In case of network congestions, the data sender will usually notice it because of the failure of data sending APIs (e.g. the BSD functions send() and sendto()).

For example I have personal experience of TCP/IP over GPRS, in which the network problems caused data sending APIs to fail. In that case it was up to the sender to preserve its data in order to send it as soon as possible.

Congestion at receiver's side

That's what the asker had actually in mind.

Let's start from UDP. Really short answer: by its own design, data sent to congested servers will be lost. From Wikipedia,EN:

[...]It has no handshaking dialogues, and thus exposes the user's program to any unreliability of the underlying network; there is no guarantee of delivery, ordering, or duplicate protection[...]

Finally TCP. It has been designed to provide what is missing in UDP. From Wikipedia, EN:

TCP provides reliable, ordered, and error-checked delivery of a stream of octets (bytes) between applications running on hosts communicating via an IP network

How are these features achieved? I cannot provide a full TCP tutorial in this answer, but I can list three TCP's fundamental traits for achieving reliability:

  1. Packets are numbered (each packet, but we can say each byte has a specific sequence number)
  2. Retransmissions. The receiver sends an acknowledge (ACK) for each packet (but we can say each byte) it receives. For this reason the sender understands that the packet has not been received and can retransmit it (the number of retransmissions allowed vary according to different implmentations and user settings)
  3. Sliding window. Let's describe it in a simply way: each peer currently informs the remote peer about its window, the number of bytes it is able to receive. As soon as a congestion occurs, a peer can reduce the windows so that the sender will slow down until the congestion ends.

To answer OP's question: in case of server congestion in case of TCP connection, the protocol assure retransmissions and throughput dynamic management that preserve for a reasonable amount of time any sent data.

I hope this simple description helps. It probably has raised even more questions, and in this case I suggest to deepen your study at the real source:

Upvotes: 1

Related Questions