Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

RFC on Net::Ping

by Falkkin (Chaplain)
on Mar 20, 2001 at 03:26 UTC ( #65577=perlmeditation: print w/ replies, xml ) Need Help??

I wrote A proposal for improvements to Net::Ping a couple of weeks ago, and have since implemented a few of my proposals, and found a few new ideas for improvements. You can check out my changes here and here. My problem is as follows: the maintainer of the Net::Ping module, Russell Mosemann, has not responded to my e-mail for the past 2 weeks. I'm assuming, since I can find no recent reference of him in comp.lang.perl.*, and since the module has not been changed since 1996, that he has basically disappeared off the face of the Perl world. I'm currently in the process on writing an Request For Comments and possibly an application for maintainership of the module to the comp.lang.perl.modules newsgroup. Before submitting the RFC to c.l.p.m., I thought I'd include it here on PM and take comments from the monks here. So, here goes:

The following is a request for comments on a list of proposed changes to the Net::Ping module. After doing some basic searching of the web, and taking a look at the actual source code, I've come up with a list of problems and changes that I am interested in implementing. I would appreciate any comments or suggestions you may have on this matter. References to web sites where I have found descriptions of some problems are given within square brackets; see the footnotes at the bottom of this message for the links. A quick search on for "Net::Ping Problems" on comp.lang.perl.* will turn up a host of problems that could be resolved if the changes listed below were made. Without further ado, here goes: - Summary - Already implemented changes: 1. Removal of alarm() function 2. TCP ping now functional on MSWin32 systems 3. Incorrect returns of "false" removed from TCP ping 4. Removal of unneeded warning in the module's POD To be (possibly) implemented: 5. Creation of a new "external" protocol 6. Creation of a new "auto" protocol 7. Documentation update 8. Change in the default ping protocol 9. Allowing for user-specified port in TCP ping 10. UDP ping fixes? - Detail - This first group of details pertains to changes I have already implemented to Net::Ping. A second group, below, discusses potential changes that I've not implemented yet. 1. The alarm() function is currently used to implement timeouts on a TCP ping. This makes Net::Ping unusable in systems which do not implement alarm() (i.e. MSWin32), [1] and may also cause problems w +ith scripts that use alarm() or sleep(). I've re-written the TCP ping code to use a non-blocking connect() and select() to implement the timeout instead. 2. On the other hand, the use of non-blocking connect() is not supported on MSWin32 either. So, I've added special code to handle TCP pings on Windows platforms. It uses Win32::Process::Create (if it exists on the system) to spawn a child process, which attempts t +o do a (blocking) TCP connect to the appropriate host. If the new process does not return before the timeout has passed, it is killed off, and false is returned. 3. The TCP pinging function, ping_tcp(), currently returns false negatives when the remote host responds with "Connection refused" (which will happen for any live machine that's not listening on the TCP echo port). [2] In this case, the call to connect() in the current Net::Ping fails, so Net::Ping returns false. However, if the error given is connection refused, this implies that there is indeed a host at the other end of the pipe, which sent the "connection refused" message. Hence, ping_tcp() should return true in this case. The changes described above in item #1 have the side-effect of removing this false negative on systems that support non-blocking connect(); specific logic written into the Win32 TCP ping handles this case for MS platforms. 4. I've also removed the POD that warns about the use of alarm() in conjunction with Net::Ping, since the warning is no longer necessary. [3] The following are potential additional changes. Comments on these would definitely be appreciated. They are ordered in roughly the order in which I would want to implement them. (In other words, easy and/or more useful things are listed first). 5. It is well-known that the most accurate method of pinging is an ICMP ping. [2] Unfortunately, ICMP ping from native perl requires privileged (AKA "root") access on all systems but VMS. To remedy this, I've written a module, Net::Ping::External [4], which interfa +ces with the native system's "ping" command for a variety of operating systems. The "ping" system utility always (AFAIK) uses an ICMP ping, so the results of Net::Ping::External are probably more reliable than Net::Ping's TCP and UDP pinging modes. Hence, I propose that a new protocol be made available to Net::Ping, called "external", which uses Net::Ping::External to do a ping. This will allow for the accuracy of an ICMP ping without the user needing privileges to run the script as root or administrator. If the user does not have Net::Ping::External installed, Net::Ping will simply croak() about the "external" protocol being currently available on their system, much like it already does if a non-root user attempts an ICMP ping. 6. I propose another protocol be added, called "auto", which is meant for "newbie" use. "auto" would automatically determine the most accurate pinging method available on the current system in the following way: * If the script is running under root privileges, the "icmp" protocol is used. * Otherwise, we check to see if Net::Ping::External is available; if so, the "external" protocol is used. * If neither of these is available, TCP ping is used. * If there is some sort of error with TCP ping, we finally fall back to UDP ping. The "auto" protocol has the main advantage of providing accurate results to people who don't care to learn about the various pinging methods and choosing the best one. A new Net::Ping object that is constructed with a protocol of "auto" would find out the appropriate protocol on the first call to the ping() method, and use that method for puture calls; hence, these checks would not need to be made for every single ping. 7. The documentation needs updating. The current Net::Ping documentation gives no explanation of why certain pinging strategie +s are better than others, or any explanation of why the module is prone to giving "incorrect" results. 8. The default pinging method is to use UDP. Since UDP seems to be the most inaccurate way of getting results, I'm not at all sure why thi +s was made the default in the first place. On the other hand, I'm not sure that I want to mess with the default that's been in place for years; there could be scripts out there that depend on it. If I were to change the default, I'd probably change it to the "auto" method, since the purpose of this method is to always return the most accurate results. 9. The TCP protocol could possibly be improved by allowing the user to specify a specific port to connect() to. If it is known that the remote host is, for example, a web server, we are more likely (due to remote firewall rules) to get an accurate result by trying a connect() to port 80 than a connect() to port 7. 10. I've not even looked at UDP ping's code yet, but there are obviously fixes that need to be made. One known issue is that UDP pings appear to not play nicely with the module on Linux [5]. Please let me know what thoughts you have on this proposal. I've tried contact Net::Ping's maintainer, Russell Mosemann, for a couple weeks now, but have gotten no response. Since the module has not been updated since 1996, and Russell has not (to my knowledge) posted to comp.lang.perl.* since that time, I'm assuming he's gone incognito. I would like to know who I need to contact, in lieu of Russell Mosemann, to submit patches to. If there is no currently-interested maintainer of Net::Ping, I think I would like to apply for maintainership of this module; who would I contact to discuss this? - Colin McMillen (CPAN ID: COLINM) References: 1.*&sa +fe=off&ic=1&th=a31c97fe6d948cc4&seekd=952924081#952924081 2. 3. 4. 5.

Comment on RFC on Net::Ping
Download Code
Re: RFC on Net::Ping
by knight (Friar) on Mar 20, 2001 at 04:01 UTC
    Nice work; you've done some careful thinking and digging on the issue.

    Your "auto" protocol is a useful and well-intentioned extension, but I'd not make it the default. Under-the-hood differences in behavior like this make for debugging problems, especially for the newbie users who are most likely to rely on the default behavior. This is doubly true for behavior that changes based on external differences not under the user's control, like whether an external "ping" is available.

    Imagine two inexperienced users debugging a network problem using Net::Ping, one from a system that has "ping" and one that doesn't. One system's Net::Ping default behavior might report the target system down because it has "ping" but ICMP messages are filtered, the other reports the target system up because it doesn't have "ping" but its TCP acks (or connection refused messages) make it through. At best, this would look like Net::Ping was inconsistent.

    Yes, you'll document this, and maybe even report which method "auto" selects, but things like that will still be non-obvious when people are under pressure to get a network back up. You'll avoid Net::Ping getting a bad rap it won't deserve if you keep the default behavior consistent.
      This is a good point.

      On the other hand, the current default, UDP, typically returns false even when pinging the local host ( This, by itself, has caused so much confusion that there are posts all over the 'net asking, basically, "Why doesn't Net::Ping work?" My general idea for fixing this problem is to always use the most accurate ping available on a given system. If people can't be bothered to read the POD, I guess I consider that their own problem. On the other hand, I think the major problem here is that the current POD gives no explanation of why some types of ping are incredibly inaccurate.

      I suppose we could default to ICMP, which would actually make most (non-root) people read through the POD before playing with the module.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://65577]
Approved by root
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
As of 2014-12-27 08:04 GMT
Find Nodes?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?

    Results (176 votes), past polls