Sometimes speed and simplicity are more important than reliability.
This episode expands on the concepts introduced in the previous episode. If you haven’t already, make sure to listen to episode 159 about TCP.
Both TCP and UDP are based on the internet protocol, or IP. UDP stands for User Datagram Protocol. Going back to the previous example of sending physical envelopes to somebody far away, let’s say that instead of sending a document split into many small envelopes, you instead need to send daily status reports.
Each status report is small and the contents don’t matter much if a few get lost. As long as most of your status reports arrive, then your friend will be happy. Because of this, there’s no need for a complicated system where you number your reports. You’ll be sending reports at a regular interval and if they arrive out of order of go missing, then the receiver can just catch up later.
You both have a lot less work to do. All you have to do is send the reports. You no longer have to wait for any replies or need to be ready to resend missing or damaged reports.
And the receiver no longer needs to send any acks or hold up processing while waiting for a missing or damaged report. It’s still important to know if a report has been damaged along the way. And UDP does provide a way to detect if a message has arrived safely or not. The difference between UDP and TCP though is that if a damaged message arrives with UDP, then it just gets thrown away.
Listen to the full episode for more explanation and examples of when you might want to use UDP. Or you can also read the full transcript below.
Transcript
This episode expands on the concepts introduced in the previous episode. If you haven’t already, make sure to listen to episode 159 about TCP.
Both TCP and UDP are based on the internet protocol, or IP. UDP stands for User Datagram Protocol and this will be a short episode today because this protocol is much simpler to explain.
Going back to the previous example of sending physical envelopes to somebody far away, let’s say that instead of sending a document split into many small envelopes, you instead need to send daily status reports.
Each status report is small and the contents don’t matter much if a few get lost. As long as most of your status reports arrive, then your friend will be happy.
Because of this, there’s no need for a complicated system where you number your reports. You’ll be sending reports at a regular interval and if they arrive out of order of go missing, then the receiver can just catch up later.
You both have a lot less work to do. All you have to do is send the reports. You no longer have to wait for any replies or need to be ready to resend missing or damaged reports.
And the receiver no longer needs to send any acks or hold up processing while waiting for a missing or damaged report. It’s still important to know if a report has been damaged along the way. And UDP does provide a way to detect if a message has arrived safely or not. The difference between UDP and TCP though is that if a damaged message arrives with UDP, then it just gets thrown away.
Think of it like getting a torn piece of junk mail yourself. It goes straight into a shredding pile or into the trash.
With TCP, a damaged message would put a hold on the entire process while the sender is notified of the problem and both sides work to arrange the safe delivery of the damaged message.
UDP is a good choice anytime you need to send a quick message or request to another computer. If the other computer needs to reply, then the same mechanism can be used. You don’t need to arrange anything more complicated than this.
Let’s say you want to send a message asking for the IP address of a given name. This can be done with UDP. Listen to episode 158 for more information about IP addresses. The reason this works well with UDP is because your request is small and can fit into a single message. With UDP, this is called a datagram. It reminds me of a telegram but more modern. The server computer can reply in the same way with a short and simple message containing the IP address requested. If you don’t get a response within a reasonable amount of time, then you don’t need TCP to handle the problem for you. All you need to do is send another request.
Another good example of when UDP is a good choice is when you need to broadcast information to one or more recipients. You can use UDP for voice or video transmission. Each datagram contains a small piece of the overall audio or video.
At first, this might seem to go against what I said earlier about not needing to break up large messages into small pieces, but the intent here is different. If you wanted to send an entire video so it can be played back later by the recipient, then TCP is better because that will make sure that all the small pieces arrive intact and in order. But if the recipient is going to play the video right away and not save it for later, then it doesn’t matter is some parts go missing. You can start processing the video right away and play what you have and then play each piece as it arrives. And if you miss some parts, then the person watching may not even notice it if the missing parts are small and the video can resume right away with current pieces.
In this case, each small piece becomes an independent message. The fact that the pieces are played one after the other doesn’t change the fact that each piece really is separate.
This is why error detection is still important for UDP. If a single small part of video is missing, then the user may not notice. But if it was instead damaged along the way and UDP didn’t notice this, then imagine that maybe the damage caused the image to turn orange or some other color that clashes with the rest of the video. Even a brief display of orange in the middle of a normal movie would definitely be noticeable. It’s better to throw away damaged datagrams like this than try to display them.