|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.