Looks interesting, though I have a feeling it may suffer from the same problem as my attempts at using fork() -- namely that fork() is simulated on Win32 using threads, and the Net::Ping ICMP ping method is a blocking operation.

What happens, therefore, is that only one ping runs at a time and the application actually takes longer to complete due to the overhead of fork().

I'll take a closer look at this when I'm in work again (since I have over 3000 machines to play with there, compared to just five here...) to see what happens on Win32.

Thanks for your response.

Gordon.

The first one I posted suffers from performance issues since it forks each time the operation runs. What I would like to know is what you mean by 'Net::Ping ICMP ping method is a blocking operation'? In a forked environment, even if it is faked by threads, you should still have each child able to run on its own, please correct me if this is not so.

The design is that each child runs independantly and when it dies the parent reaps it. Depending on the return status of the child that died the parent either continues on to reap another, or sends and SNMP trap.

The second program on my scratchpad however is much more resource friendly. It preforks a number of child processes which do not exit. The list of destination information is handed out one by one to the child processes and if they fail they are logged to a database via another processes. There is yet another child processes who's only job is to monitor the database of failures and report in whatever you set to be a failure (7 failures in 10 minutes, etc) and clean out the old entries.

Since the child processes all stay running the parent which hands out the IP's logs what time each was handed out and will only hand it out once every 60 seconds. What happens is that due to failures and other latency the program balances itself out over time. This has the effect of spreading out the pings over the 60 second (configurable) interval to lessen the load on the server as well as the network.

Let me know if you have any more questions on this second program. It will probably have much more work to port to a Win platform though.

Have you ever considered running this in cygwin? Is there a *nix box you could put it on? Just because you are checking windows boxes dosen't mean all your tools have to run on one.

Well... I'll have to admit that I don't know the fundamental problem here, only the observed behaviour. I wrote some fork code that pinged a few thousand machines. When the pings timed out it appeared to be a blocking operation, since no other pings would occur until the timeout expired (i.e. the pings on other forked threads would just pause).

I tested the code on Linux and it worked perfectly, however on Win32 this blocking occurred, and the script was no quicker than a series of sequential pings. The advice I got at the time was that it was due to the way Net::Ping implemented its ICMP echo send/receive process.

The post by meetraz in this thread seems to contradict this theory, as it uses threads and Net::Ping. So the bottom line is that I don't know and would love for someone to conclusively explain it!

I'd prefer not to use Cygwin when I can use ActivePerl. Cygwin has its uses, but I prefer using a 'pure' Win32 version of Perl on Win32 :) I do have a Linux box I could run this on, however I find it easier to access SMB shares via UNC from Win32. But that's going to be the subject of my next post...

Cheers,

Gordon.