Relying on Ping
Published: 01/29/2008
You open your browser, type in a website address, press Enter, and ... um ... nothing shows up. It looks like it's waiting for something, but there's only white space appearing in your browser window. Then all of a sudden you get a "The page cannot be displayed" message.
Some amateur techie types will instantly tell you that you're having a connectivity problem. They might be right. Do you have an IP address? Can you reach another website? Can you reach the default gateway? Can you "ping the host?" If you can't "ping" the website, then it must be down!
This sort of rush-to-conclusion really irks me.
And therefore here is a quick-and-dirty introduction to the concept of ICMP and why it's not always a reliable indicator of remote host availability.
So what is this "ping" thing anyway?
Just imagine a submarine trying to figure out how far it is from a distant ship. It sends out a sound burst towards the ship and eventually an echo comes back from it. The time it takes for this echo to come back gives the submarine crew an idea how far away that ship is.
In the computer networking world, a similar tool exists in the form of a communication protocol called ICMP (Internet Control Message Protocol). Fancy acronyms aside, several utilities built into the operating system make use of this protocol. The most common one that everyone uses is called ping.exe (in Windows XP, this is located under "C:\Windows\system32", also referred to as "%SystemRoot%\system32" in unnecessarily-sophisticated IT parlance). If you open a command-line window and run the following command:
ping www.google.com
your computer constructs a data packet with an "echo-request" message and sends it out of your network interface. This packet, a type that is formatted with ICMP-specific details, is marked with the destination address of www.google.com. Assuming that the path to the destination is working, the www.google.com server receives this message, notices that there's an "echo-request" contained within it, and decides to send a response known as a "echo-reply" back to you. This ICMP packet with the "echo-reply" travels all the way back to your computer where your operating system receives it and shows you some of its contents:
Pinging www.l.google.com [72.14.253.147] with 32 bytes of data:
Reply from 72.14.253.147: bytes=32 time=41ms TTL=245
Reply from 72.14.253.147: bytes=32 time=37ms TTL=245
Reply from 72.14.253.147: bytes=32 time=39ms TTL=245
Reply from 72.14.253.147: bytes=32 time=37ms TTL=245
Ping statistics for 72.14.253.147:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 37ms, Maximum = 41ms, Average = 38ms
If you use the ping utility on Windows, by default it sends out four of these requests. You can see the four replies above, each showing its payload size (32 bytes), latency (in milliseconds), and its TTL (Time-To-Live) value. It automatically does some simple averaging for you at the end because it figures you failed basic math a long time ago. If you ran this command on a Unix / Linux machine, it would keep sending and receiving these forever until you manually stopped it.
So, I guess if we get replies back, the server out there is alive. Does that mean if there are no replies, the server's offline?
Well, not so fast.
If you went to a social gathering and tried to talk to people at random, you're probably going to run into two scenarios: some people will be completely open and willing to start a conversation, and yet others will just shut you out and not give you the time of day unless you're attractive and look like you have money. Picky.
On the Internet, some servers are part of the latter group. For various reasons (security may be one them), a server will be receptive only to certain types of requests, such as HTTP (web) requests from users. However, they may completely filter out ICMP traffic. When the server receives traffic from somewhere on the Internet, it looks at the packet and figures out whether it's something they'll deal with (like HTTP) or if it's something else. If it's something else (like ICMP), they might just "drop it." Dropping a packet in networking terminology essentially means that the server takes the packet, turns around to the trash can behind it, and throws it away. It sounds rude, but some servers are self-conscious of these things.
Moral of the story: servers, firewalls, and computers on the network in general have the ability to filter out traffic based on specific needs. Just because you don't get an ICMP response from the server doesn't mean it's down.
Go back to the main articles list.