Once this has been discussed, I plan on doing the Nice Thing and e-mailing the module's author regarding the proposed changes; I'll have to see what kind of response (if any) I get from him before I go too much further. At any rate, here are the suggestions:

• When a TCP ping is sent to a system's echo port, the system often disallows the connection, sending back a "connection refused" message, which is interpreted by Net::Ping as an indication that the remote system is down (because the connect() call on line 312 of the current code fails). However, the existence of said message implies that there is indeed a live system on the other end of the pipe. I've already implemented a fix for this behavior; this already makes TCP much better as a viable pinging method.

• ICMP ping is probably the most reliable way of getting a correct ping result. The problem with ICMP ping is that it requires "root" or "administrator" privileges on most machines. To get around this, I suggest that a new "proto" option be available, called "system", that runs the system's default ping command, in backticks, and attempts to analyze the system ping's output to return a proper value. If the system we're running under appears not to have a ping command, we simply return a message that states that the "system" option is not available on their system.

• Another new "protocol" we might want to use is "auto". The "auto" protocol would first try a normal ICMP ping. If we are denied ICMP privileges by our system (as is likely), we then fall back to TCP or UDP; if this fails, we try using the system's ping command, as described above. It may also be possible to do ICMP pinging (at least for Win NT systems) through calls to the native system API; this would be a bit ickier, and not something I'd necessarily want to tackle any time soon.

• alarm() isn't implemented on Windows systems. On Windows systems, we could replace functionality that is currently supported by an alarm() call (i.e. the TCP ping timeout) by using Win32::CreateProcess (or fork(), which is hopefully at least semi-functional in Windows for perl > 5.6.0) to create us a new child that attempts to do the appropriate pinging, and is killed by its parent if it's not returned in the alloted amount of time. If we could implement timeouts with fork() or CreateProcess() instead of alarm(), we could also get rid of the warning situation noted in the POD:

  pingecho() or a ping object with the tcp protocol use alarm() to
  implement the timeout.  So, don't use alarm() in your program while
  you are using pingecho() or a ping object with the tcp protocol.  The
  udp and icmp protocols do not use alarm() to implement the timeout.
  [download]

• A new feature we may want to have is the ability to do a parallel ping of many hosts. I'm pondering a call like:

  $p = Net::Ping->new();
  $p->ping(\@list_of_hosts, $timeout, $num_forks);
  [download]

  This call would fork() $num_forks children and have each of them start attempts to ping different hosts in the @list_of_hosts until the list is empty. All hosts in the list which are alive will be returned by the call to ping(). This would be especially useful for pinging a largish network of computers: in general, an attempt to ping n hosts will occur in worst-case time of n * $timeout / $numforks instead of n * $timeout. If fork() or CreateProcess() is not implemented on the system, this call would issue a warning, and then start pinging each of the hosts in sequence, returning the list when done.

Also, I have no easy access to a Windows NT box w/Perl (I've only got access to Solaris, IRIX, Linux, OpenBSD, and Win9x boxen here); if I end up going ahead with this and need an NT box to test on, would there be any monks willing to help me out? Anyone else who has a more exotic system would also be of use for testing.

Thanks in advance for any input you may have.