More and more I see programmers developing web based applications that are based on what I call "ping-then-do" mentality. An example would be the application that pings the mail server before sending the mail. In a rather heated debate in another forum I made this statement, "If you are going to write programs that use the internet, you should at least have a basic idea of the fundamentals. The desire to "ping-then-do" tells me that many who are, don’t."
On this forum and at Stack Overflow I see numerous questions about ping / trace route and wonder why? If it is acceptable to have a discussion about it here I would like to hear what others think. If not I assume it will be closed rapidly.
One clarification - I want to be clear that I am talking about internet traffic, not private networks.
In my experience, many programmers don't understand what ping is and what it is not. I have often encountered those who think that if they can ping a thing, they can then use X service running on that thing. And there are also those who think that if they can't ping it, then they can't use it. Both assumptions are false.
That being said, we can't restrict networking applications to only those who fully understand networking anymore than we can restrict database applications to those who fully understand databases. If we did, we would see a lot fewer applications and programmers would encounter a lot fewer teachable moments.
I'm not convinced that this doesn't belong on meta, but it's a slow morning, so what's the harm?
ping, particularly, is one of those tools that has a low barrier of entry and provides a high degree of usefulness for a small amount of effort. It's also one of the first diagnostic tools that someone learns in networking. This means that a lot of people of varying skill levels have exposure to it.
The underlying mechanisms are pretty well unexposed directly to the end user of ping. The new user can instantly tell if a host is up or not. At least, that's what they think they see. As an experienced user, you know that isn't always the case. Which is the problem with using ping as your only diagnostic tool.
It isn't an indicator that something is up or down. It's an indicator of response time. A lack of a reply has no bearing on whether or not a host receives traffic, but that's how it's used, because most hosts respond to ICMP packets. I still have relatively knowledgeable users who swear remote servers are down if they don't respond to ICMP.
The result is that as long it's used by users who are ignorant of its purpose, there will be questions. The bonus is that these questions give us the opportunity to improve the knowledge of the people asking.
As for traceroute, it's a really complex tool that seems really simple. "If I traceroute this IP, I see all the computers in between it and myself", as though the internet was a series of tubes, like a subway, where you could see the stops between yourself and your destination.
As you know, the internet doesn't work like that. Routes change all the time. There's no guarantee that two packets will traverse the same path (or even that the ICMP response will traverse the same path that the source took). That doesn't mean that traceroute isn't useful, but that it requires a higher level of knowledge to interpret.
Again, when people ask traceroute questions, we should see it as an opportunity to educate, rather than an excuse to abuse them.
Error handling is the most underestimated capability in programming, and the least tested as well. If a piece of code does a "ping" or "traceroute", it must have very good reasons to do so. E.g. in addition to sensing "I can't reach the mail server" the code may elaborate and write a ping and traceroute dump to logs. This can be very useful if your network topology is buggy, but only at 4am.
Detect service failure in detail first, then do diagnostics. Suggesting everything is okay by judging host diagnostics would be foolish.
A point in ping-then-do might be the fact that most TCP based protocols have rather long timeouts and programmers try to spare users from waiting. Doing actual pings is still wrong here, though. Detect mail server failure in a separate process, reconfigure to use backup server. There's clean solutions to about every fail situation without using ping.
What prompted me to start this was that I got down voted for simply asking why someone was doing a trace route to google.
There was a guy I knew at a place you'd know if I told you. We were together quite often in the maintenance window at o'dark thirty and he would find people with noticeable patterns of ping then download. He loved to to block ICMP on those ports for a few minutes. That was 15 years ago and I am sure that stuff doesn't happen anymore. Oh the stories I could tell. We were all surprised at how fast the internet backbone grew.
My very strongly held opinion is that an application should never ping, then do something, unless the application is some form of network monitoring tool used by network administrators.
I am the network administrator of my home network, and I am three long haul WIFI links from my ISP's pop, so at times I have spotty service. I don't ping Yahoo when I have problems, and the apps I write don't either.
There are programmers out there who, even when it is explained, still think ping-then-do is good. I went back and forth with one guy at on one forum. He posted code showing why, and I posted his code back fixed, he was sending mail as I recall. This went on for two or three times and his last response was that the error message from the ping failure was better than the error message from the send mail failure. You gotta love it.
If anyone has an example of when ping-then-do IS a good idea, post it here.
hmm if your a hacker lighting up a process on a remote machine is not a good thing, you need to gather other info 1st. If your hacking an important/secure site and they do let icmp (not likely) in then they will have ids/ips running and if you light that thing up too early... tr