160: UDP: User Datagram Protocol.

Take Up Code - A podcast by Take Up Code: build your own computer games, apps, and robotics with podcasts and live classes

Categories:

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