TCP/IP First-Step [Electronic resources] نسخه متنی

User Datagram Protocol

The User Datagram Protocol, or UDP, is another transport layer protocol suite in TCP/IP. You can think of UDP as the unsung hero of TCP/IP. TCP gets all the recognitionit even gets top billing in the protocol suite's name! UDP is a wonderful complement to TCP.

Figure 9-1 shows an overview of the architecture so you can see that TCP and UDP are truly peers. Between them, there's seemingly nothing they can't handle.

Functionally speaking, TCP and UDP are truly peers. Both occupy Layer 4 of the OSI reference model and both serve as an intermediary between applications that need to communicate with the Internet Protocol (IP). In other words, UDP accepts data from application software packages and prepares it for handoff to IP. It forms the middle ground between an application that requires network communications and the networking protocol (IP, in this book).

As you see throughout this chapter, both perform their intermediary role using similar tools. UDP just has a lot fewer tools to work with! That simplicity is not a design flaw; it's a design feature. UDP was specifically designed to provide your applications with a type of delivery service that is known as best effort.

What Do You Mean, Best Effort?

To some people, giving their best effort means trying as hard as they can until they succeed. Anything less than success isn't their best! UDP, however, doesn't quite work that way. You can take that a step further and wonder how best effort can mean anything but a guarantee of delivery. In other words, having seen the effort that TCP expends to guarantee delivery of data, how can anything less be considered a best effort? Before you can appreciate the solution to that conundrum, you must accept that sometimes less truly is more!

The phrase takes on a completely different connotation in UDP/IP communications. There are no guarantees or complicated mechanisms needed to fulfill any guarantees. UDP's best effort is to make one attempt at delivering the data. That's a simple and straightforward goal, so it shouldn't be any surprise that UDP is every bit as simple and straightforward.

Built for Speed

After you see how UDP works, it should be fairly apparent that UDP was built for one purpose: speed! Thus, best effort from UDP's perspective is to make one attempt at delivering application data as quickly as possible.

The benefit of a quick delivery mechanism might not be readily apparent. Time is the enemy of some applications. Think back to the last time you made an international telephone call. You probably noticed a slight delay that made conversation a little awkward. That delay is known as latency.milliseconds (ms).propagation delay. Propagation delay measures the theoretical minimum amount of time required for your data to pass through all the network pipes and devices it needs to reach its destination.

Other things, too, can slow down your data. These things are not an innate part of your network (despite what your Internet service provider might tell you!) and, consequently, are known as delays. Network conditions such as heavy traffic volumes and the need to retransmit can add greatly to the innate latency of a path between a source and destination machine. Not surprisingly, feature-rich protocols such as TCP can also add quite a bit of time to this process!

Under heavy load conditions is where UDP can really shine. UDP is such a frugal and minimal protocol that it does not add substantially to the total amount of time required to move a packet between a source and destination machine. It will incur a modest amount of time, but not so much that you noticecertainly not when viewed in terms of the latency introduced by the switches and pipes that comprise the physical path between the two machines. Thus, with UDP you have eliminated one potential source of delay. Now all you have to deal with are the congested pipes in your ISP's network!

The Header's Shape

UDP's header is about as concise as any protocol's header can possibly be and still function. It contains just the following fields:

Source Application Port Number
The first 16 bits of the UDP header contain the application port number of the application sending the data.

Destination Application Port Number
The next 16 bits contain the application port number of the application that receives this data.

Length
The next 16 bits identify how long the datagram is in bits.

Checksum
The last 16 bits of the UDP header are reserved for the checksum value. Checksum, if you recall my discussion of this earlier, is an error-detection mechanism. The source machine runs a mathematical algorithm on the datagram. Remember: The contents are inherently binary, so you can run a mathematical algorithm against these Base2 numbers regardless of what they translate into! The destination, or recipient, machine runs the same formula on the datagram. If the results match, you can be reasonably sure that the datagram wasn't damaged en route.

This header gets stuck on the front of application data and that resulting structure becomes known as a datagram. The datagram gets handed off to IP where the IP header gets stuck on it. That structuredatagram plus IP headeris known generically as a packet and more specifically as an IP packet.

Looking more closely at the UDP header should reveal just how lean this mean machine really is! You have just enough information for the datagram to reach its intended destination application and for UDP on that receiving machine to figure out if the received data is worth passing on.

One could argue that the inclusion of the source application port number is superfluous and could be eliminated. After all, UDP gets used for one-way data dumps! Despite the apparent logic of that claim, UDP can be used for more than just shoveling real-time data in one direction. For those functions, the inclusion of a return address (i.e., the source application port number) is worth the effort.