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
http://groups.google.com 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 Socket.pm 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. http://groups.google.com/groups?hl=en&lr=&group=comp.lang.perl.*&sa
+fe=off&ic=1&th=a31c97fe6d948cc4&seekd=952924081#952924081
2. http://www.perlmonks.org/index.pl?node_id=42739
3. http://search.cpan.org/doc/RMOSE/Net-Ping-2.02/Ping.pm
4. http://search.cpan.org/search?dist=Net-Ping-External
5. http://www.perlmonks.org/index.pl?node_id=55508
[download]