Coding Horror: The Story About PING

January 5, 2007

The Story About PING

Everyone loves ping. It's simple. It's utilitarian. And it does exactly what the sonar inspired name implies. Ping tells you if a remote computer is responding to network requests.

the PING command

The ping utility was written by Mike Muuss, a senior scientist at the U.S. Army Research Laboratory. Mike also wrote ttcp, which I'm a big fan of. I've used the PC port of ttcp many times to test network throughput.

Mike was tragically killed in an automobile accident 7 years ago, but his legacy lives on in Ping:

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. 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.

Ping isn't very useful on today's internet because most routers and hosts filter it out. But it's still quite useful on local networks; not a month goes by that I'm not pinging something. Ping is always a solid starting point, but sometimes you'll need to perform deeper network diagnostics, too.

Of course, we can't talk about ping without mentioning one of the most famous Amazon book reviews of all time.

PING! The magic duck!
Using deft allegory, the authors have provided an insightful and intuitive explanation of one of Unix's most venerable networking utilities. Even more stunning is that they were clearly working with a very early beta of the program, as their book first appeared in 1933, years (decades!) before the operating system and network infrastructure were finalized.
The book describes networking in terms even a child could understand, choosing to anthropomorphize the underlying packet structure. The ping packet is described as a duck, who, with other packets (more ducks), spends a certain period of time on the host machine (the wise-eyed boat). At the same time each day (I suspect this is scheduled under cron), the little packets (ducks) exit the host (boat) by way of a bridge (a bridge). From the bridge, the packets travel onto the internet (here embodied by the Yangtze River).
The title character -- er, packet, is called Ping. Ping meanders around the river before being received by another host (another boat). He spends a brief time on the other boat, but eventually returns to his original host machine (the wise-eyed boat) somewhat the worse for wear.
If you need a good, high-level overview of the ping utility, this is the book. I can't recommend it for most managers, as the technical aspects may be too overwhelming and the basic concepts too daunting.
As good as it is, The Story About Ping is not without its faults. There is no index, and though the ping(8) man pages cover the command line options well enough, some review of them seems to be in order. Likewise, in a book solely about Ping, I would have expected a more detailed overview of the ICMP packet structure.
But even with these problems, The Story About Ping has earned a place on my bookshelf, right between Stevens' Advanced Programming in the Unix Environment, and my dog-eared copy of Dante's seminal work on MS Windows, Inferno. Who can read that passage on the Windows API ("Obscure, profound it was, and nebulous, So that by fixing on its depths my sight -- Nothing whatever I discerned therein."), without shaking their head with deep understanding. But I digress.

It's a timeless geek humor classic. The original was posted in March 1999 by an anonymous reviewer from "Upper Volta, Uzbekistan". It must have been deleted by Amazon, because it was reinstated by another reviewer later in 2000.

You may be familiar with the command line version of Ping, and maybe even the book, but did you ever play the arcade version of Ping?

It's milliseconds of fun for the entire family.

Posted by Jeff Atwood View blog reactions

« The Sugar UI

Please Stand By.. We're Experiencing Technical Difficulties »

Comments

Yes, it is a very simple, but useful function. I sometimes ping Google to find out if there is some problem with the Internet connection. Another useful, complementary utility is "tracert" (Windows) which gives more details about routing.

Krishna Kumar on January 7, 2007 6:59 AM

Interesting that you ping www.yahoo.com in your screenshot. For some reason, that's my habit when testing an internet connection. I always ping yahoo. I wonder how much ping traffic they get.

Haacked on January 8, 2007 9:40 AM

I think it's because ping predates Google.. and Yahoo was around much earlier.

Jeff Atwood on January 8, 2007 9:57 AM

From a linguistic perspective, of course, hardly a day goes by when I don't ping someone to get their insight/opinion/schedule on something, or to remind them about something. I am guessing that a fair percentage of people where I work who say "I'll ping so-and-so" don't know exactly where this comes from.

mike on January 8, 2007 10:00 AM

I always do this to troubleshoot connectivity at a wifi spot, etc:

ping 4.2.2.2 (easy to remember and doesn't need DNS)
ping www.google.com (to test DNS)
telnet www.google.com 80 (to test HTTP outbound and DNS)

It takes 5-10 seconds, and you know that everything *should* be working after that. It's also incremental in nature in terms of the stack, so you'll know what the issue is based on how far you've made it with those three tests.

BG on January 8, 2007 10:44 AM

Here's my tip.

Use "ping -t (host)" to repeatedly ping a server while it's restarting, rebooting, etc.

You'll know it's back up when it is responding to pings..

Jeff Atwood on January 8, 2007 10:47 AM

The arcade classic Pong was called Ping in the UK, as "pong" here is slang for a noxious odour :-)

Nick Fitzsimons on January 8, 2007 11:16 AM

Do you know that ping can be used to tunnel TCP traffic? Here is a link: http://www.cs.uit.no/~daniels/PingTunnel

zvikara on January 8, 2007 12:08 PM

ping and the corisponding protocol it is based upon, is blocked on campus.

they use something else to test avalibility.

apeinago on January 8, 2007 7:19 PM

Mike was brilliant, if a bit idiosyncratic. I had the pleasure and honor of working with him early in my career. I remember watching in awe as he implemented a virtual memory object system, entirely in C, so that we could fit our large CAD models into a PDP-11's address space (64K (not M) bytes of data and 64K bytes of program). It took him maybe a day or two.

We used it to compute this object: http://www.cs.utah.edu/gdc/pics/images/bulkhead1.gif, and I'm pretty sure, this more complex one, too: http://www.cs.utah.edu/gdc/pics/images/blades.gif

Mike was a hacker, in the best sense of the word. He may have written code quickly, but it was never dirty. Our world is poorer without him.

Spencer on January 8, 2007 7:35 PM

As an interesting side-note is that traceruoute (which is a "relative" of ping :)) on linux uses UDP, not ICMP by default. Here are some links about this topic: http://hype-free.blogspot.com/2006/10/traceroute-on-windows-and-linux.html

Cd-MaN on January 8, 2007 9:58 PM

If 'ping' works on your local Windows network, and you've not enabled file sharing or otherwise opened TCP port 445 (e.g. through Group Policy), it may be a sign that Windows Firewall is not enabled. In its default configuration, Windows Firewall rejects ICMP Echo Request packets.

Ping itself probably isn't harmful - although it gives attackers an indication that a host is alive - but leaving your computers open to attack definitely is. You may think you're secure but if you have any users with laptops that they take home or to customer sites, it's quite possible for them to get infected off-site then infect everyone else when they bring the laptop back to the office (or onto the VPN). Don't trust any other machines - use a software firewall.

Mike Dimmick on January 9, 2007 1:43 AM

The "Story About Ping" book review originally appeared in
Slashdot back in 1999:

http://books.slashdot.org/article.pl?sid=99/01/31/1246212

I know, because I wrote it. It's been lifted and reposted elsewhere since then -- always without attribution of course.

Doc Technical on January 9, 2007 5:05 AM

Categorical blocking of all ICMP is something that ignorant security paranoid people do. It drops out "ping" too.

At the same time they break TCP Path-MTU, and when IPv6 comes into true use, they break their entire network.

In many web-site cases the published one/two IP addresses for the site are actually handled by a "load-balancer switch", which diverts incoming TCP connection flows to real back-end servers. At the same time they don't (at all) support ICMP redirecting - which may cause surprising effects with TCP Path-MTU.
(All the world can carry full-size ethernet frames of 1500 bytes each? Yeah, right... Consider PPPoE, and realize that present world is by default running with "don't fragment" bit set..)

traceroute can use ICMP too, but original UNIX traceroute used UDP, thus all its UNIX descendants use that by default, while some can use also ICMP.

Matti Aarnio on January 9, 2007 7:04 AM

I find it sad nobody mentioned the "ping of death". If you flood pinged windows (95?) machines, they would become unresponsive and then either BSOD (blue screen of death) or reboot, I don't remember which.

mike on January 9, 2007 3:58 PM

Actually, the "ping of death" was not a flood of ICMP Echos. It's simply one ICMP Echo with over 65536 bytes in the payload directed at a host. Remember, 64 bytes is the default. The packet would be fragmented in order to be transmitted to the destination due to its size being larger than the MTU. The receiving host would attempt to reconstruct the overly large packet from the fragments and overflow a buffer causing itself to panic/hang/need rebooting/reboot.

BG on January 9, 2007 4:57 PM

And you might also find this entertaining (and serious) explanation of how traceroute works useful in explaining it to your less technical colleagues: http://samspade.org/d/traceroute.html

Timothy Knox on January 31, 2007 1:37 PM

I was wondering, if my kid brother was on the xbox 360 online all day and one day I got tired of it, but he was smart enough to check to see if everythings plugged in, is there a way that I could ping the xbox on the network to make it lag bad or time out or something?

tony on August 21, 2008 12:53 PM

The ping screenshot shown isn't the real Mike Muuss ping!

http://ftp.arl.mil/~mike/ping.html is Mike's ping page, showing the output of his version of ping.

Mark on September 7, 2008 12:54 AM

nurislam

karsan on January 6, 2009 3:36 AM