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

Yeah, but What's It Good For?

By this point in the chapter, you should have a fairly good appreciation for what UDP does for you. Now it's time to make that appreciation a bit more real. UDP excels at providing a transit service for real-time applications. In practical terms, two broad application categories qualify as real time and need UDP's services. These are voice over IP (VoIP) and streaming video.

It's important to not overgeneralize here. You can't assume that UDP is custom built for delivery of voice and video over networks. Those two, voice and video, are two types of data rather than being two types of applications. Remember: It is the application's network performance requirements that matter, not the data! Just because you know what type of data is being transmitted doesn't mean you know whether you are using UDP or TCP. Let me give a few examples so you can see how fine a line there can be between transport protocol choices.

Video Varieties

Transmitting video across the Internet (or any IP network for that matter) is always an interesting task. A video clip can be generated by at least two different types of applications. For example, one use of video data is downloading a video file from an Internet news site to see what's happening in the world.

Another use is creating and sending video data in real time. For creating and sending video data in real time, the video doesn't live on a hard-disk drive. For example, you might have an IP-based camera installed in your home for security purposes. That would enable you to keep an eye on your home no matter where you go. Of course, that's a proverbial double-edged sword: If you can keep an eye on your home, everyone else on the Internet can, too!

Those two examples of video over IP allow me to show you the spectrum of possibilities for transporting video files. These two applications might use the same file type. For the sake of argument, assume that both use .mpg files. That's not an unreasonable assumption. It will help demonstrate that you can't tell anything about an application's network performance requirements by looking at the data it uses. In general terms, these two application types can be classified based on whether they create their data in real time.

Real-Time Video

The example of a video camera being used for security surveillance is a good one to demonstrate the implications of real-time video transmission. The camera creates video data but does not necessarily store it anywhere. Instead, that data would be immediately available via the network.

Your video-based security system poses some interesting challenges. This data, even though it uses the exact same file type as your downloaded news video, never lives on a hard drive. Its existence is transient, as is its purpose! You probably don't care what happened to your home five minutes ago (assuming, of course, that nothing actually happened). You are much more interested in what's happening right now. Consequently, if a piece of data failed to arrive on time or were damaged you wouldn't want to waste any time getting it delivered correctly. You would simply want to move on to the next picture.

In other words, you wouldn't want or need any of TCP's features. Using those features might even cause you problems! Losing a video frame because of a network problem might mean that you lost one second's worth of video display. That would show up as a temporary glitch or less-than-smooth transition from one video frame to the next. Not great, but not so bad either.

Using TCP to transport live video images would cause two glitches from the viewer's perspective:

The first glitch would occur when the frame was expected but failed to arrive. Because the application needs this data in real time, you don't have the luxury of waiting until it is successfully retransmitted. The data also doesn't have to be sequenced because it isn't part of a larger file structure (such as a file or series of files). As quickly as data is received, it gets passed onto the application and promptly displayed for the viewer.

The second glitch would occur when that tardy piece of data finally arrived and was passed onto the application for display. Clearly, the right solution for real-time applications such as this one is to use UDP. You don't want or need TCP's features, and UDP is built for speed, which is exactly what your application requires.

Not-So-Real-Time Video

One of the biggest problems understanding UDP's role in a TCP/IP network is caused by overgeneralizing. It is common to find people, even knowledgeable people, stating that UDP is always used for voice and video communications. Although UDP does excel at transporting real-time communications (including voice, video, and online gaming), it is not always used. In fact, UDP would only be used for real-time transmissions. Transmissions that aren't quite real time would be better off with TCP as the transport protocol.

That means that how you use data is more important than what that data is when it comes to deciding between TCP and UDP as your transport mechanism. Walk through an example to see. The example is downloading a video clip from an Internet news site. That video clip might someday prove to have lasting value. It might be today's news, but it is tomorrow's history. Thus, you might want to save it for future viewing. Alternately, it might be of passing interest and not worth saving.

When you try to download a video clip from an Internet news site, it is not uncommon to get a pop-up box from your Windows operating system. That pop-up box asks if you want to run the file from its current location (i.e., the remote server's hard-disk drive) or if you would prefer to save it to your own computer for running whenever you like.

This decision point is significant: It's the same video clip regardless of which option you choose. What differs, however, is the transport protocol.

You won't see that spelled out for you, nor should you even care. If you choose to save a downloaded file to your hard disk drive, you are tacitly acknowledging that the file has lasting value. Consequently, you want that video to be complete and perfect. You would first save it to disk and then open and run it in your favorite media player. TCP would probably be the best choice of transport protocols for this purpose.

Because you are saving it to disk first, you have the luxury of time to make sure you get all the data intact. That includes retransmitting any data that was lost or damaged in transit and being able to reassemble all the pieces back into the right sequence. In other words, you need all TCP's capabilities for this communications session.

If, however, you chose to just run it from its current location, you are tacitly acknowledging that the clip is of just passing interest to you. You probably won't be looking at it again and again nor do you want to waste storage space on your own computer. Instead, you are choosing to view it in real time.

This set of circumstances imposes a completely different set of network performance requirements! Even though the file and application are exactly the same, the difference is in how you are using them. This approach more closely resembles the usage characteristics of a real-time video stream even though it is a canned file. The data isn't being created in real time as would be the case with live voice or video communications. However, you will be viewing it in real time. Consequently, UDP is much more appropriate.

Sound Options

Although you have seen how network performance requirements can vary for applications that use the same type of data using video, this comparison is valid for other types of data as well. For example, transmitting sounds over a network presents the exact same set of circumstances. Those sounds can be encoded using .wav file type, but used in different ways. Just like video, you can use a .wav as a file that lives on a hard disk and can be sent around just like any other disk-bound file. Alternately, you can convert the sound into a .wav format and play it live over a network.

The days of college students actually having a telephone (as well as a stereo) in the dorms have come and gone. Today, they are much more likely to just have a laptop and a cell phone. Set up properly, both allow them all the functionality of yesterday's stereo and land-line telephone. More to the point, using a laptop instead of a stereo and a telephone demonstrates the use of both TCP and UDP to move sound files across a network.

A laptop can act like a stereo by playing digitized music. (Hopefully, this digitized music was legally purchased rather than just swapped illegally using peer-to-peer software across the Internet.) Regardless of how you acquired it, the fact is that the songs in your collection are digital files that get stored on your hard disk drive. They have lasting value and you will likely play them time and again. Thus, you want to be sure that they are perfect and complete when you download them. The only way to do that is to use TCP.

A laptop can also act like a telephone and, in the process, enable a frugal college student to evade the historically pricey long-distance charges of phone calls home. Unlike digital songs, telephone conversations transmitted over an IP network are of a fleeting nature. They do not get stored on a hard disk drive. The sounds of your voice get digitized in real time as you utter them and are sent in real time across a network. It makes absolutely no sense to recover a half-second's worth of conversation. You and your conversation partner both noticed the glitch and moved on. For this type of application, UDP is your only choice.

These examples illustrate the differences between UDP and TCP as they relate to applications and their network performance requirements. These examples, however, might not be indicative of the way such applications actually work! The bottom line is that you can't judge an application by the type of data it uses. You must look at the application, what it does, and how it does it before you can start figuring out which transport protocol would be best. Fortunately, application developers solve this problem for you but it never hurts to understand what's going on when you launch your favorite applications.

Sound files also can be played across a network from their source location rather than saved locally. In such cases, you are using the file in a manner that more closely approximates real time and are better off using UDP to handle that download.

It Gets a Little More Complicated

I'll reserve my opinion on the increasingly obfuscated nature of today's software and merely point out that it is a rare software package that only performs one function. Instead, each piece of software tends to have a dizzying array of functions. Each discrete function within a software package has its own network performance requirements to consider. The protocol that is right for one application subfunction probably won't be right for all.

The point is that even though this chapter led you to believe that an application is either designed to work with TCP or UDP, the truth is that it is quite common for an application to use both. The catch is that an application can use both UDP and TCP. It would just use them for different functions.

Up to this point, the book presented a rather sanitized perspective of TCP and UDP. This chapter repeatedly points out how you don't have to worry about selecting a transport layer protocol because your applications do that for you. This chapter also suggests that each application has its own performance requirements and that those requirements guide the choice between TCP and UDP. All that is true enough, but there is one small detail omitted for the sake of clarity.

You see, even though an application automatically selects the right protocol to use doesn't mean it must continue using that one protocol for all its needs! Application software has gotten complex enough that it's hard to think of any one piece of software that only does only one thing. Instead, software today tends to have so many bells and whistles hanging that it is sometimes difficult to see the application itself! This is another one of those dangerous generalizations that can lead you astray: You just can't say that this application uses TCP or UDP. The truth is most software applications use both TCP and UDP for different functions.