How does UDP clients/servers "know" how much bandwidth is available

Kaiden Prince 0
Viewed 19

I'm about to attempt to make a high bandwidth application that talks to both computers in the local lan as well as over the internet. UDP has become appealing due to it being stateless, and due to its multicast features for LANs.

It's come to my attention though, that I don't know how to handle a slow connection between two fast computers. Lets say computer A and computer B are infinitely fast. However, at some point in the network there is a bottleneck of 512kbit/s. What happens if you try to send more than the bottleneck allows? How does this differ from TCP?

Does the packet just get dropped, and you have to implement the error handling to both resend the packet and raise/decrease a limit of bandwidth you set yourself? Does what needs to be done change based on your operating system?

language-agnostic udp network-programming
1 Answers

UDP is best suited for probabilistic systems, that are okay with missing data. For example if a real-time voice connection over UDP loses packets, it is acceptable to just let the user hear a cut in the audio instead of trying to fix the packet loss.

Of course, some crude error correction and detection is often useful to implement. However whenever you do this you are on a spectrum that terminates with reimplementing TCP. So if you can get away with very rudimentary handling of packet issues, then UDP is fine. If you need more sophisticated protection of your traffic, maybe UDP is not the best approach.

The bandwidth is a good example. The sender could keep count of how many packets it sent since a given time and periodically send that to the recipient along with the other data. The recipient could use this simple count and time range to determine that they are getting only about 10% of the packets that were sent, and perhaps ask the sender to use a lower fidelity format. This is not very complicated and works as a crude measure. However if you try to do stuff like send an index of all the packets you sent, so that the recipient can figure out a list of missing ones and ask for them, you are getting into the reimplementing TCP region.

As for what exactly happens with a bottleneck, it depends on what exactly the bottleneck is. If it puts the packets in a queue, the recipient will observe a time dilation (packets arrive in "slow motion") and ultimately an abrupt stop (when the bottleneck runs out of packet buffer and crashes). Or the bottleneck may just drop packets when it's busy, so in effect it will be like every packet has only x% chance of being transmitted successfully.

With TCP, the ack message will start to be delayed or fail to arrive. TCP is quite complex, but in essence it will notice these missing acks and throttle down the transfer rate. The connection should automatically adjust itself to be around 512 kbps after a while. Unlike UDP, this is automatic without the application programmers having to implement any specific mechanisms.

evansrhonda0
Related