December 16, 2004

By Karen Kenworthy

IN THIS ISSUE

Got a call from Mom and Dad! They've witnessed the wonders off the coast of Cozumel from a glass-bottom boat, and visited a banana plantation in Costa Rica. Next stop: the Panama Canal. Dad, ever the engineer, can't wait to see those amazing locks!

Meanwhile, back at the secluded Power Tools workshop, the weather experts say we might see sunshine in day or two. The morning temperatures will still be well below freezing. But hopefully it won't feel quite so cold if the wind doesn't blow. <sigh>

Protocol Stacks

Until the sun returns, it's a good day to stay inside and talk about computers!

Remember the last time we got together, and chatted about the Internet Protocol? As we saw, it's the foundation for all communication between computers across the unimaginable tangle of wires and optical fibers known as the Internet.

The Internet Protocol answers two important questions. It describes how moving data should be packaged (in an "IP Datagram"). And it details how senders and recipients should be identified (by their "IP Address").

At first, the IP Protocol might seem pretty complete. But it leaves some important questions unanswered.

For example, the IP Protocol can't guarantee data will be delivered to its destination. It only promises to try for a specified amount of time, or to make a certain number of attempts. Undelivered datagrams are simply discarded, with no explanation or notification given to the poor sender.

The IP Protocol has another shortcoming. Its IP Addresses identify the computer where data should be sent. But they reveal nothing about what should happen to that data once it arrives.

Imagine a computer's dilemma. Several times per second a block of bits arrives, bearing your IP address. It's clear the data is meant for you. But what does the data mean? Which program, running on your CPU, consuming your memory, should process the data? Should it be processed at all, or should it be ignored?

If you or I were to try to answer these questions, we might modify the Internet Protocol. Perhaps we'd expand the IP Address, adding the name of a program, or a description of the data's purpose. We might also change the rules governing the delivery of IP Datagrams, ensuring that senders are told of undeliverable data.

But the designers of the Internet took a different, and very ingenious, approach. They left the IP Protocol intact. Instead, they created several additional protocols. These protocols don't replace the IP Protocol. Instead, they build on its foundation, creating what computer folks call a "Protocol Stack".

UDP and TCP and ICMP. Oh My!

The last time we looked at the IP Datagram, we saw it contains more than the actual data being transmitted from one computer to another. Extra information precedes the data, in a region known as the "header".

Naturally, the header is where we find the IP address of the computer sending the data. The IP Address of the intended recipient is there too. In the header you'll find the datagram's length, priority, and "Time-To- Live".

The header even contains a checksum, or mathematical hash of the datagram's contents, used to detect any corruption of the data while in transit. And, as we saw the other day, there's a field called "Version" that indicates which version of the Internet Protocol best describes this datagram.

But there's more. One field in the header is called "Protocol". Seems odd, doesn't it? After all, every IP Datagram must conform to the Internet Protocol. So, what do the values stored in this field mean?

According to the Internet Protocol, "This field indicates the next level protocol used in the data portion of the internet datagram." In other words, the nugget of data found in the datagram isn't just a blob of bits. It has a structure. It's organized according to the rules of yet another protocol!

In fact, there are over two dozen officially recognized protocols which can describe the data stored in an IP Datagram. Each of these protocols turns a bland IP Datagram into a "packet", a datagram on a mission.

Most of these protocols, such as PUP (PARC Universal Protocol) or DCN (Distributed Computer Network protocol), are rarely used nowadays. But three protocols account for nearly all of the packets traveling across the Internet. Network gurus know them by their initials: UDP, TCP and ICMP. But if you're not on such familiar terms, let me introduce them to you ...

User Datagram Protocol (UDP) This protocol describes simple packets used for very brief conversations between computers. In fact, the word "conversation" might be misleading. When a computer receives a UDP packet, it usually sends a one-packet reply. And that's the end of the "conversation".

The User Datagram Protocol introduces one important innovation. Each UDP packet carries a 16-bit binary number known as the destination "port". The value of this port determines which program, on the receiving computer, will process the packet's data.

For example, UDP packets addressed to port 42 contain requests to translate a computer's name, such as www.microsoft.com, into the computer's IP Address, such as 207.46.245.156. That's why computers deliver those packets to a program known as a Domain Name Server (DNS) -- software that performs those sorts of translations.

Transmission Control Protocol (TCP) Packets conforming to this protocol are used for more complex conversations. Often, computers will exchange several TCP packets over a period of time. A field in the TCP packet allows each packet to be sequentially numbered, so receiving computers can detect packets that get lost along the way. The would-be recipient can request a retransmission of a wayward packet, asking for it by its unique serial number.

Where can you find TCP packets at work? They're as close as your computer's desktop. TCP packets are used to send and receive e-mail messages, transmit downloaded files from remote computers, and retrieve pages from the web.

One of my programs, the LAN Monitor, reveals when these conversations are taking place. It shows all programs that are currently "listening" to a UDP port -- waiting for UDP packets addressed to the particular port. And it lists all active TCP conversations, showing the port being used and the remote computer taking part.

Internet Control Message Protocol This protocol's packets allow computers to talk about themselves, and the Internet. They can be used to report errors, or to notify a sending computer of a better route to a destination.

Programs like my 'Net Monitor send ICMP packets to "ping" remote computers. If one of these special packets arrives at its destination, the receiver immediately responds with a ping packet of its own. If the ping completes the roundtrip, we know the two computers can successfully communicate over the Internet.

Higher and Deeper

Whew! So far we've seen protocols stacked two-deep. The UDP, TCP and ICMP protocols ride along, inside datagrams defined by the venerable Internet Protocol.

But we haven't reached the top of this digital Tower of Babel. Other protocols specify how UDP and TCP packets should be used to accomplish various tasks.

For example, the HyperText Transfer Protocol (HTTP) sets the rules for the delivery of web pages to our web browsers. According to the protocol, special web server software "listens" for incoming TCP packets addressed to port 80. When a packet arrives, requesting a particular web page, picture, or sound file, the requested file is dutifully sent by the server via more TCP packets.

Other popular protocols that sit atop TCP and IP include the Simple Mail Transfer Protocol (SMTP), used to send e-mail, and POP3 (Post Office Protocol version 3), used to receive e-mail messages.

My "Time Sync" program understands three of other high-level protocols. Two of them, the "Daytime Protocol" and the "Time Protocol", can communicate using either UDP or TCP packets. The third, the "Simple Network Time Protocol" relies exclusively on TCP packets. All three perform the same service -- revealing the current time and date to any computer that asks.

And that just scratches the surface! There are many more protocols which guide your computer every day. If you'd like to learn more about some of them, check out these official standards available on the web:

TCP/IP Tutorial
http://www.ietf.org/rfc/rfc1180.txt

Internet Protocol
http://www.ietf.org/rfc/rfc0791.txt

Internet Protocol, Version 6 (IPv6)
http://www.ietf.org/rfc/rfc2460.txt

User Datagram Protocol
http://www.ietf.org/rfc/rfc0768.txt

Transmission Control Protocol
http://www.ietf.org/rfc/rfc0793.txt

Internet Control Message Protocol
http://www.ietf.org/rfc/rfc0792.txt

Hypertext Transfer Protocol
http://www.ietf.org/rfc/rfc2616.txt

Post Office Protocol - Version 3
http://www.ietf.org/rfc/rfc1939.txt

Simple Mail Transfer Protocol
http://www.ietf.org/rfc/rfc821.txt

File Transfer Protocol
http://www.ietf.org/rfc/rfc0959.txt

Daytime Protocol
http://www.ietf.org/rfc/rfc0867.txt

Time Protocol
http://www.ietf.org/rfc/rfc0868.txt

Simple Network Time Protocol
http://www.ietf.org/rfc/rfc2030.txt

And if you'd like to give my 'Net Monitor, LAN Monitor, and Time Sync programs a try, visit their home pages at:

    https://www.karenware.com/powertools/ptnetmon

    https://www.karenware.com/powertools/ptlanmon

    https://www.karenware.com/powertools/ptsync

As always, all three programs are free for personal/home use. If you're a programmer, you can download their Visual Basic source code too!

Better yet, get the latest version of every Power Tool on a brand-new, shiny CD. You'll also get three bonus Power Tools, not available anywhere else. Source code of every Power Tool, the text of every issue of my newsletter, and some of my articles written for Windows Magazine, are also included. And owning the CD grants you a special license to use all my Power Tools at work.

Best of all, buying a CD is the easiest way to support the KarenWare.com web site, Karen's Power Tools, and this newsletter! To find out more, visit:

    https://www.karenware.com/licenseme

Whew! That was a lot of techie talk. Hope I didn't put you to sleep. But if I did, I hope you have a nice rest. And when you awake, if you see me on the 'net, be sure to wave and say "Hi!"