Re: RFC on Net::Ping

[knight]

Nice work; you've done some careful thinking and digging on the issue.

Your "auto" protocol is a useful and well-intentioned extension, but I'd not make it the default. Under-the-hood differences in behavior like this make for debugging problems, especially for the newbie users who are most likely to rely on the default behavior. This is doubly true for behavior that changes based on external differences not under the user's control, like whether an external "ping" is available.

Imagine two inexperienced users debugging a network problem using Net::Ping, one from a system that has "ping" and one that doesn't. One system's Net::Ping default behavior might report the target system down because it has "ping" but ICMP messages are filtered, the other reports the target system up because it doesn't have "ping" but its TCP acks (or connection refused messages) make it through. At best, this would look like Net::Ping was inconsistent.

Yes, you'll document this, and maybe even report which method "auto" selects, but things like that will still be non-obvious when people are under pressure to get a network back up. You'll avoid Net::Ping getting a bad rap it won't deserve if you keep the default behavior consistent.

[Falkkin]

This is a good point.

On the other hand, the current default, UDP, typically returns false even when pinging the local host (127.0.0.1). This, by itself, has caused so much confusion that there are posts all over the 'net asking, basically, "Why doesn't Net::Ping work?" My general idea for fixing this problem is to always use the most accurate ping available on a given system. If people can't be bothered to read the POD, I guess I consider that their own problem. On the other hand, I think the major problem here is that the current POD gives no explanation of why some types of ping are incredibly inaccurate.

I suppose we could default to ICMP, which would actually make most (non-root) people read through the POD before playing with the module.