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!"
More than 6000 downloads monthly
Received $184.68 this month* — Thanks!
License for Work
A license is required to use any or all of these tools for your work. You only need one per lifetime. If you make money with Karen's software, read her license agreement.
Power Tools Newsletter
- What is Karen's QR Code Talker?
- What is a QR code?
- What is a Code Talker?
24836 Verified Subscribers
Subscribe to receive new issues of the newsletter about Karen and her free Power Tools.
Click here to SubscribeNovember Revenue* $184.68
*Licenses + Donations - PayPal Fees
Oct $211 Sep $166 Aug $173 Jul $225 Jun $324 May $200 Apr $700 Mar $273 Feb $405 Jan $56 (2023) Dec $349 Nov $546 Oct $253 Sep $232 Aug $189 Jul $379 Jun $188 May $484 Apr $212 Mar $519 Feb $89 Jan $462 (2022) Dec $1088 Nov $151 Oct $133 USD — Thanks again!