Subject: | SYN Pings need a reliable queuing method |
Date: | Thu, 01 Nov 2007 13:56:24 -0700 |
To: | <bug-Net-Ping [...] rt.cpan.org> |
From: | "Richard Kelsch" <richard.kelsch [...] napster.com> |
I have the need to SYN ping many thousands of hosts, not just a few or a
small class C. The Net::Ping code makes no checks for the number of
file handles, nor the number of forks it spawns. This is very
unreliable. There needs to be a queuing mechanism for SYN pings that
either takes an array of addresses to SYN ping or queues each single
ping to be sent to the ping forker in a safe and reliable manner. Just
blindly spawning of ping forks can be dangerous and actually slow down
ping responses, due to process overhead to the CPU.
Net::Ping, in its current form just happily spawns as many forks as you
send it, which really "angers" the operating system.
Perhaps having a special variable that can be set for
"maximum_processes" or "maximum_threads" (if using a more modern
threaded model) and the code queuing the remainder of the calls. Also,
having another variable or subroutine call that checks to see if any
forks (or threads) are remaining so slow ack responses aren't missed.
Such a method could be easy to implement using an array (I do it all of
the time for other uses):
1. push the address on the array, no matter what.
2. Have the forking loop check to see if any "slots" are open to
fork (or thread) a ping. If so, then pop the next address off
the array. This routine can run continuously after the object
is created in its own thread, if threading, If no addresses,
then it just yields processor time back to the system.
3. The results of a ping can merely be added to a hash (or hashes)
that can easily be retrieved via ack() or nak().
4. The "new" subroutine that checks if there are ping threads/forks
remaining could just merely return a true or false. That way,
results wouldn't be missed or ignored, and timeouts wouldn't
have to be blocking.
This method allows one to dump thousands of addresses (believe me, where
I work there are thousands, but most unused) into the syn ping mechanism
and not have to worry about getting slowed down waiting for each class C
part of the tree to scan before I continue on.
Thanks, for your attention. It's a great utility so far.
Richard Kelsch
Perl Programmer Napster LLC
This correspondence is from Napster, Inc. or its affiliated entities
and is intended only for use by the recipient named herein. This
correspondence may contain privileged, proprietary and/or confidential
information, and is intended only to be seen and used by named addressee(s).
You are notified that any discussion, dissemination,distribution or copying
of this correspondence and any attachments, is strictly prohibited,
unless otherwise authorized or consented to in writing by the sender.
If you have received this correspondence in error, please notify the
sender immediately, and please permanently delete the original and any
copies of it and any attachment and destroy any related printouts without
reading or copying them.