udp is user data Graham Protocol. And
the biggest thing to remember about UDP is that UDP is connection less.
Ew. DP does not have to verify a connection before it starts sending data. UDP doesn't do a three way handshake. UDP doesn't care if the data got there or not. It's not literal. It cares that the data got there, but it's not going to verify that the data got there. It's not gonna wait for read receipt.
It's not going to number. It's packets. It's not gonna perform retransmission.
It's not even limited toe one toe, one communications. We may send UDP over broadcast. We can send broadcast packets that air UDP because if we're sending a broadcast message, we don't necessarily want anything back. So we're just sending these packets broadcast over UDP.
why would we use your GP?
Why would we want to send a packet or send any data at all that we don't verify that it gets back that it that it got there or that we don't want to verify that we can re transmit it if it's corrupted?
Well, think about streaming video
if you're streaming a video that's taking a lot of bandwidth, especially with those high quality Netflix everybody has, or the high quality online HBO that everybody that only a couple people seem to have, Um, you're streaming video and you're streaming a lot of bandwidth.
if every time a single packet of data got to you that was a video packet,
the server would have toe Wait. If it was, if you were running over TCP connection, the survey would wait for you to communicate back to it and say, Yeah, I got this packet
before sent the next one.
You think you have problems with buffering now? Imagine if the server had toe wait for you to respond back and say, Yeah, I got this back before sent the next packet. It would be ridiculous.
So that's why we used T. U T P For certain things. UDP is when our priority is making sure it gets there and gets there fast or it gets there and it just streams as live as possible.
So that's our big That's our big deal with you, T P.
Now UDP is also useful for small packets because our UDP header is a lot smaller, it's only eight bites. We don't need those
12 other bites because we don't have all that other information. Like which packet this is, or making sure that the packets not corrupted So we don't have all that other information. TCP numbers their packets, and they also put in check sums to make sure that the packet isn't corrupted. If he doesn't care.
UDP is only gonna have that eight byte header. It's connection list. We don't perform a three way handshake. We don't wait for a read receipt. We just send these packets.
There's no error recovery if a package is recovered. If a packet is received and it's corrupted and it's UDP oh, well,
you'll get you'll get a video that's a little bit fuzzy, or you may get say, you have a Skype conference call with somebody and may break up a little bit. But you know, when the connection gets restored,
your computer isn't gonna back up to that point in that Skype call and then re start over again. It's streaming, it's just gonna keep going. And those broken up packets Oh, well,
So there's no Aargh recovery. They're small packets. We mentioned their small packets, so because they only have eight byte header size and
we have here that they're distinct chunks
now what we mean by distinct chunks.
Compare that with our data streaming from our TCP
now our TCP Like we said, because our boxes are numbered because our packets are numbered and they're ordered, we can just fill those packets up all the way. It doesn't matter if the end makes sense or not, and then descend it because our next packet will pick up where it left off
UDP that matters. What goes into those packets have to make sense within the context of whatever next product, whatever next level protocol or whatever program we're using is because if that program receives a packet and it doesn't get what that saying the next pack it may not be
the next intended packet.
The next pack, it may get dropped or the next packet may get corrupted so we can't send. We can't send a full box of UDP,
so you d a full beauty p packet
and then just say, Oh,
I can't this UDP packet I'm gonna have to I'm gonna take this data and I'm gonna fill the UDP, pack it all the way up, and I'm just gonna cut this data off in the middle of a conversation and then pick it up with the next packet. It'll be okay. Guess what?
That next packet may not get there or maybe collected because you're not performing
a connection oriented connection. You're more worried about just how fast these packets get there. So you may have UDP packets that are not using their full packet size because they're breaking up into logical chunks. They're breaking their pack it up into data that if our program or our next level protocol
didn't receive this packet but on Lee received
this packet in this packet, it would be able to understand the message without the context of this packet.
That's why file transfers can't be UDP. That's why we don't want file transfers. That we want to make sure that the files are correct can't be UDP because if we're transferring a file, we're breaking up that file at illogical points because we can't fit the whole file into a single packet. So we've got to break it up at points that don't make sense in the context of
opening that file in a program.
If we lose a packet, that file's corrupted.
So we have to transfer with TCP because we need to make sure that every packet gets there and it gets there, and it's not corrupted in this in the right order.
that's our two communications protocols. That's our difference between TCP Transmission Control Protocol and UDP User Data Graham Protocol
and again, our communications protocols, T. C, P and U. T P R. What let our next level protocols that we're about to talk that we'll talk about it a little bit. That's how they talk now. Not all of the different protocols that we've talked about or we'll talk about
are using TCP or UDP to know how to communicate.
For example, we've talked about routing protocols. Such a CZ rip
are simply protocols which analyze information
and develop information for routing tables.
Those protocols aren't delivering data anywhere.
Those protocols aren't sending messages or downloading pages from Web servers, so they don't really they don't need a communication protocol toe work with them. They don't need a communication protocol to know how to transmit their packet sizes. They're just working with I P addresses, and they're working with information that there
observing about the network.
So that's how our communications protocols TCP and UDP work with our next next level protocols. That's why our TCP and you DPR layer four because they know how to transport data, they know how to break up packages. Think about TCP and Rud Pia's our as our FedEx and our ups
sort of our transport layer,
and we'll move into our next
different protocols, and we'll talk more about how are other protocols are either T c, P, R U D P and how those other protocols work with different amounts of with different types of data.