Ping vs HTTP HEAD

Question

I'm writing a Java app which has a feature to check whether it's connected to the internet by periodically trying to access a server. My first idea was to Ping the server - but turned out to be complicated to achieve in Java. So I remade it to send HTTP HEAD requests and check for the HTTP response code instead. I have two questions:

1) Are HTTP HEAD requests "as reliable" as pings? Ping would be my first natural choice to check if something is available. Maybe just because it's so easy to run on the command line.

2) If I send HTTP HEAD requests to a third-party website to check if it is accessible, is there some standard frequency at which these should be sent? Eg if I send them every second, would that be discouraged or even get me blocked from those services?

Answer 1

An HTTP HEAD is generally more reliable than a ping, as ICMP connections are often blocked and HTTP is usually open. Checking for a connectivity every second sounds pretty excessive, but it really depends on your use case what third party site you are trying to "ping".

Answer 2

I can't comment on whether its more effective to use HEAD or trying to do something like drop to the system and do a ping; but I don't think either of them is the solution you should be doing. IMHO, it isn't necessary to poll your connection. There are a lot of situations where a connection could be dropped and I don't think polling will provide much in the way of mitigating the problem. Also, the user might be annoyed. I know that if I were using an application, and then started doing something else, and all of a sudden I got a "connection lost to 3rd party error" from an application I wasn't even paying attention to; I would be very annoyed.

If your application depends on a connection being present, then I think its fair to handle this with exception handlers. I'm willing to be bet that whatever API you're using throws some kind of exception whenever you attempt a network action and you aren't able to establish a connection. So, what I would do is in whatever class you're initializing the network action, I would follow this paradigm:

try {
  performNetworkAction();
} catch (NoConnectionFoundException e) {
  // handle the situation here
}

Your application shouldn't be able to determine when a connection was lost, just how to react when you attempt a network action and no connection is found.

That being said - you still may disagree with me. If that is the case then the frequency of polling allowed/recommended might be documented in the API for the service you're using. Also, if the resource from the 3rd party is static, you should cache it as opposed to getting it over and over again.

Answer 3

I wanted to expand @Dave's answer, and a comment would not suffice.

1. When you lose internet connectivity, a java.io.IOException is thrown. Look at the sub-classes of IOException - UnknownHostException, SocketException and ProtocolException are the ones that usually smell of "No Internet Connection"
2. Create a central place for handling exceptions (this is good practice in itself). If you get any of the IOException's I mentioned above, set isInternetAvailable to false.
3. Instead of polling for internet connection, switch to retrying the operation you want to perform. You achieve the same thing
4. Use a backoff strategy - exponential backoff works great. For example, after it fails the first time, you wait for 5s. After the second failure, you wait for 25s and so on. Gmail webapp uses this strategy. Twitter commons has utility classes for backoff.