Re: Re: A proposal for improvements to Net::Ping

I'll respond point-by-point as well.

1. No response needed. ;)

2. Perhaps the user would specify, through a method, which command-line to run as the system ping utility. Future pings that needed the "system" mode would run the appropriate program. I do agree that just arbitrarily allowing any user to merely call `ping` without thinking about it first is up for trouble. The point regarding not attempting to circumvent ICMP restrictions is taken.

3.Perhaps I was unclear here. Only one attempt to ping the remote computer would be used. What I'm intending here is to first try doing a normal ICMP ping; if the system disallows ICMP, we fallback to TCP or the system's ping command. I agree that perhaps this functionality should not be built directly into Net::Ping, but a new Net::Ping::Extras module (insert a better name here if you like) that extends Net::Ping with more functionality (AKA code bloat).

4. alarm() is already used in the current Net::Ping code. I'd be attempting to remove the current usage of alarm() from the module. So I'm assuming you'd be okay with this change?

5. I agree this functionality constitutes code bloat, too, and I agree that it probably shouldn't be stuck in Net::Ping. It is something I would want to add to a new module (i.e. Net::Ping::Extras). The point of the $num_forks option is to only use as many forks as the user desires -- I don't see any need to fork off 20 processes, unless your script were trying to repeatedly ping a thousand hosts.

What do you think of this newly-modified proposal?

Comment on Re: Re: A proposal for improvements to Net::Ping Select or Download Code

Replies are listed 'Best First'.

Re: Re: Re: A proposal for improvements to Net::Ping
by AgentM (Curate) on Mar 10, 2001 at 06:06 UTC

Check.
I'm not sure building this functionality into this important module is worthwhile at all since the string returned from `ping` is completely arbitrary, system-dependent, and variable even during the lifetime of a system. That's bad news. Having to parse such a string from the module would be difficult if not impossible to anticipate. I don't really see a benefit of including this in a module since the user is free to call `ping` at anytime anyway and know the system specifics beforehand.
Example:
- Here's the ping output from a Solaris server:
```
% ping www.agentm.com
www.agentm.com  : #####

www.agentm.com  :   5/5   succ. = 100.00%
[download]
```
- And the more familiar Linux-brand generic ping:
```
PING worf4.agentm.com (208.185.131.199): 56 octets data
64 octets from 208.185.131.199: icmp_seq=0 ttl=244 time=216.6 ms
64 octets from 208.185.131.199: icmp_seq=1 ttl=244 time=216.1 ms
64 octets from 208.185.131.199: icmp_seq=2 ttl=244 time=247.6 ms
64 octets from 208.185.131.199: icmp_seq=3 ttl=244 time=235.3 ms

--- worf4.agentm.com ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 216.1/228.9/247.6 ms
[download]
```
The output is completely arbitrary and impossible to anticipate. (Note that agentm.com does not belong to me as it should! Copyright stealing bastards!)
alarm was a poor choice to start off with. The options I mention above are far better suited for the task. History: alarm is a very old function (much older than select) and was used for similar tasks as here. It is now best to avoid this function altogether. I can't even think of a use of it in a modern threaded system.
Again, if the user wants to do this, he can easily cough up a for loop to fork off ping requests, even using the module. I'd say, more than not, modules are looked towards for "good programming style", especially for beginning users. Including this would constitute teaching bad, yet functional, programming style. Honestly, again, I don't see the benefit to including this in an important module as this one. But, if you see the need to do this, perhaps name it Net::Ping::Parallel and warn about its use profusely. If you specify a number of forks less than the number of hosts to ping, you will be using some fairly heavy-duty IPC, putting reliance on yet another module and more system resources. I would definitely AT LEAST keep such code away from the standard Net::Ping. Feel free to msg me if you need additional clarification. Good luck!

AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

[reply]
[d/l]
[select]


P is for Practical
	PerlMonks