[music] Good day, viewers. In this segment, we'll learn about the user datagram protocol, or UDP. Udp provides the datagram service at the socket layer and I've said before, it's really a glorified layer on top of IP, which really allows packets or datagrams to be delivered. So in this segment we'll learn the ins and outs of, of what's behind UDP. And the answer is really not a lot more than IP itself. Okay, so UDP as a datagram protocol, an unreliable one at that, it's used by applications that either don't want reliability, or they don't want some other kind of obstraction their messages, such as a byte stream. So there are several examples here. One example is a voice-over-IP application. Typically for real-time conferencing, we don't want reliability there, so UDP is a good fit. Other kinds of protocols that might use messages would be the DNS and R. Pcu stands for remote procedure call, we haven't actually seen the DNS yet. We'll see it later but its the machinery that maps between host names like dub, dub, dub dot U dub dot DDU and addresses, IP addresses. And may be a third class would even be bootstrapping protocols such as DHCP since these are used to get the network going its easier in some sense if they're to rely on all of the complex machinery or TCP By the way you can see from this, from this list of reasoning that if an application wants both reliability and messages then it has work to do. Udp gives you unreliable messages. Tcp gives you a reliable bytestream, reliable messages for somebody in between. So, for instance, protocols that want that, like the DNS, must provide the reliability themselves as part of the application level. Protocol. So, in that sense, the internet protocols, TCP and UDP, aren't a good fit to all applications. Okay, so we can see how datagrams are used at the circuit layer. Let's see. Here's is a simple time sequence diagram. We have a client and a server. The client is sending a request to the server, who is returning a reply. The circuit call who would mate to cause this to happen would be first of all we would need a socket on both sides. Now, on the server side we need to bind that socket to an address, a well known port so that the client could contact. So we now simply want to send a datagram. What do we need to do? Well, usually the server will call receive, in this case receive from, to receive a message. That's a blocking call, so that really says I want to receive a message and the process then blocks while the kernal waits for the message to come along. At some later time the client will call send it to, to send their request from the client to the server. At this stage the receive from COBOL and block and we'll have the information then. And the server can then process the request. On the client side right after sending to, since we'll be expecting a reply, we'll send, we'll call receive from. From, this instructs the client now to wait for a message. And after the server has finished processing the request it will send. It will send that reply using send to. And then the receive from call will be unblocked, the reply will be received by the client and the client will process it. And then at some later time, when everyone's done, they'll call close to tidy up. So those are the sequence of socket calls which is used with a datagram sockets for a very simple client server exchange. I've cleaned it up here on this figure, and you might note that I've just starred the calls which block. Which sort of explains how the flow of programs. Okay, so that' how you use a Datagram Socket. We did see examples of using sockets previously, a long time ago, in the course, but they were for stream sockets, the datagram sockets are slightly different. No connections and slightly different forms of receive and send. We can also look at what's going on at the host, while we make all of these calls. This picture here shows the buffering that happens inside the transport layer. We have the application layer at top, so this is all of the app processes which are running. They use the sockets and ports to interface to the transport layer. And at the bottom of this picture, we have packets, and they're going out the physical network, so I'll just draw a wire. Now this buffering inside the transport layer, when an app calls or actually when segments come in from the from the transport peer on the other side, they're placed in these buffers inside the kernel. Can see that the sum circuits. There are many different segments sitting here in the buffer. They're going to wait there until the app call is received at which time they'll be pulled from the kernel and handed up to the application. Similiarly an application might have data to send and when it does, if it calls send too, that data goes down. To the kernel, where it sits in a buffer temporarily. An application might send more quickly than that information could be put on the local network y, in which case there'd be a little bit of temporary buffering inside the kernel. But as you can see here, the setup is fairly simple. We just have that buffer as a staging point between the send and receive operations down at the bottom here. This block saying Port Mux/Demux, is simply the multiplexer in the multiplexer, which is using the port information when you get a segment in, to assign it to the right queue. And vice versa, taking segments from all of those queues and sending them out then into the network. Network. Well, there's not too much more we can look at for UDP. I can show you the header. You'll see the header is actually very simple. It's pictured here. It has the ports. Those 16 bit ports which identify the sending and receiving application processes. It has a length field. You can send datagrams. [inaudible] about, to 64 kilobyte in length. There's also a check sum, a 16 bit internet check sum, just for a little bit of added reliability. But this is pretty much IP. There's only one other thing I can think of to tell you. And that's a little bit about the check sum. The checksum here, well first of all its optional. But second, it covers not only the UDP segment, but it also covers the IP addresses that are passed down by the UDP segment to the data layer. Now these are checksum by placing them in the form of what's called an IP pseudoheader. You can see a picture below here, the source address is in a little bit of information. The checksum covers this block, prepended to the UDP segment. It's a little unusual that we would have these source addresses here inside the transport layer, it almost sounds like a layer violation. It's not quite because these are parameters that the UDP layer knows and is passing down. Sorry, the UDP as a transport layer protocol is passing down to the network layer, to tell it where to send things. But it does show you some of the linkage between layers that we often conveniently ignore. And a final trick is that value 0 in the checksum. Means there is no checksum, that's how it's optional. With a quirk about ones compliment checksum, there are two different values for zero. So if the checksum comes up to really be zero, we can send it in the form of all ones. That's an equivalent value for zero. Rather than all bit zero, which would indicate there's no checksum. That's it. That's UDP.