The History of Ping
by Terry Slattery
Everyone doing networking these days knows about the ping program. What is often not known is how it originated. I happened to be a by-stander and was able to see it being created. The real story about ping is found on a web page written by Mike Muuss, the author of the original version of ping:
(Here’s Mike’s story)
The Story of the PING Program
Yes, it's true! I'm the author of ping for UNIX. Ping is a little thousand-line hack that I wrote in an evening which practically everyone seems to know about. :-)
I named it after the sound that a sonar makes, inspired by the whole principle of echo-location. In college I'd done a lot of modeling of sonar and radar systems, so the "Cyberspace" analogy seemed very apt. It's exactly the same paradigm applied to a new problem domain: ping uses timed IP/ICMP ECHO_REQUEST and ECHO_REPLY packets to probe the "distance" to the target machine.
My original impetus for writing PING for 4.2a BSD UNIX came from an offhand remark in July 1983 by Dr. Dave Mills while we were attending a DARPA meeting in Norway, in which he described some work that he had done on his "Fuzzball" LSI-11 systems to measure path latency using timed ICMP Echo packets.
In December of 1983 I encountered some odd behavior of the IP network at BRL. Recalling Dr. Mills' comments, I quickly coded up the PING program, which revolved around opening an ICMP style SOCK_RAW AF_INET Berkeley-style socket(). The code compiled just fine, but it didn't work -- there was no kernel support for raw ICMP sockets! Incensed, I coded up the kernel support and had everything working well before sunrise. Not surprisingly, Chuck Kennedy (aka "Kermit") had found and fixed the network hardware before I was able to launch my very first "ping" packet. But I've used it a few times since then. *grin* If I'd known then that it would be my most famous accomplishment in life, I might have worked on it another day or two and added some more options.
The folks at Berkeley eagerly took back my kernel modifications and the PING source code, and it's been a standard part of Berkeley UNIX ever since. Since it's free, it has been ported to many systems since then, including Microsoft Windows95 and WindowsNT. You can identify it by the distinctive messages that it prints, which look like this:
PING vapor.arl.army.mil (128.63.240.80): 56 data bytes
64 bytes from 128.63.240.80: icmp_seq=0 time=16 ms
64 bytes from 128.63.240.80: icmp_seq=1 time=9 ms
64 bytes from 128.63.240.80: icmp_seq=2 time=9 ms
64 bytes from 128.63.240.80: icmp_seq=3 time=8 ms
64 bytes from 128.63.240.80: icmp_seq=4 time=8 ms
^C
----vapor.arl.army.mil PING Statistics----
5 packets transmitted, 5 packets received, 0% packet loss
round-trip (ms) min/avg/max = 8/10/16
In 1993, ten years after I wrote PING, the USENIX association presented me with a handsome scroll, pronouncing me a Joint recipient of The USENIX Association 1993 Lifetime Achievement Award presented to the Computer Systems Research Group, University of California at Berkeley 1979-1993. ``Presented to honor profound intellectual achievement and unparalleled service to our Community. At the behest of CSRG principals we hereby recognize the following individuals and organizations as CSRG participants, contributors and supporters.'' Wow!
From my point of view PING is not an acronym standing for Packet InterNet Grouper, it's a sonar analogy. However, I've heard second-hand that Dave Mills offered this expansion of the name, so perhaps we're both right. Sheesh, and I thought the government was bad about expanding acronyms! :-)
Phil Dykstra added ICMP Record Route support to PING, but in those early days few routers processed them, making this feature almost useless. The limitation on the number of hops that could be recorded in the IP header precluded this from measuring very long paths.
I was insanely jealous when Van Jacobson of LBL used my kernel ICMP support to write TRACEROUTE, by realizing that he could get ICMP Time-to-Live Exceeded messages when pinging by modulating the IP time to life (TTL) field. I wish I had thought of that! :-) Of course, the real traceroute uses UDP datagrams because routers aren't supposed to generate ICMP error messages for ICMP messages.
The best ping story I've ever heard was told to me at a USENIX conference, where a network administrator with an intermittent Ethernet had linked the ping program to his vocoder program, in essence writing:
ping goodhost | sed -e 's/.*/ping/' | vocoder
He wired the vocoder's output into his office stereo and turned up the volume as loud as he could stand. The computer sat there shouting "Ping, ping, ping..." once a second, and he wandered through the building wiggling Ethernet connectors until the sound stopped. And that's how he found the intermittent failure.
Mike named it after the sound made by sonar. If you've seen the movie The Hunt for Red October, you may recall the scene where Sean Connery, captain of the Red October, issues the command to his chief, "Give me one ping, Vasily." That's basically what the network version of ping does. Is the remote destination reachable?
It was funny a few years ago (like 10 years?) to see people trying to turn PING into an acronym with phrases like Packet INternet Groper. Plausible, but as the MythBusters say, "Myth Busted!"
I happened to be visiting Mike the evening he created ping (he often worked late into the night). He was an incredible software developer, producing high quality software at a rate that was ten times what other developers could create. He had great insight into the right way to solve problems. He and I worked together on the Test TCP (ttcp) program as well (see the comments in the TTCP source).
Several years ago, someone sent Mike a copy of a book The Story About Ping, which is the story of a duck. Several web sites around the net have stories about this book, with the one on slashdot being primarily referenced: Review: The Story About Ping
So, the next time you use ping, think of Mike and "Give me one ping."
-Terry
Terry Slatery asked us to post this invitation to join the Cisco Mid-Atlantic Users Group (C-MUG). The folks over at Chesapeake Netcraftsmen are a brain trust and are creating a forum to share information with any interested network engineer in the region. Go check it out and tell them Eman sent you!
Cisco University is now the Cisco Mid-Atlantic User's Group!
Chesapeake NetCraftsmen is proud to announce the formation of the new Cisco Users Group for the Mid-Atlantic area. The Cisco Mid-Atlantic Users Group (C-MUG) has evolved from the Cisco University presentations sponsored by the Virginia and Maryland Cisco sales teams. The new Cisco Users Group will continue to bring you top-notch technical presentations and information on the latest Cisco technologies and products.
Terry Slattery is Presenting at VoiceCon Orlando Mar 30, 2009 - VoIP Troubleshooting, Monitoring and Metrics Mar 31, 2009 - Network Management: Finding the Right Tools
Terry Slattery is scheduled to presented two sessions at VoiceCon Orlando!
On Monday Mar 30, his session is a half-day tutorial titled "VoIP Troubleshooting, Monitoring and Metrics" that helps attendees:
- Learn how to identify and troubleshoot VoIP problems
- Understand how to configure your network management system to monitor key network factors that impact VoIP
- Learn the metrics that indicate an adverse impact on VoIP operation
The Monitoring and Metrics section will describe how to watch your VoIP system and the network on which it operates, as well as key metrics like call failures, call performance characteristics, network congestion, and QoS that can be used to proactively identify potential problems.
On Tuesday Mar 31, he will be the speaker at a breakout session on "Network Management: Finding the Right Tools". In this session, he will present a taxonomy of the network management technology marketplace, which will help attendees understand the metrics and methods that drive successful IP Telephony management. Some key questions he will adress include:
- What are the key metrics you must measure and manage?
- What tools are available to capture these key metrics?
- How can you get visibility on the level of voice quality actually being delivered?
- How does the management of voice systems fit into the overall enterprise IP network management structure?
- What will it cost to implement an effective network management system? Where can you garner cost savings?
Return to the top of The History of Ping .
Send Feedback