Problems? Is your data what you think it is? | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
2) I disagree with all of your points. But I think there are enough complexities here "we" should avoid letting it delay other enhancements. If you don't want non-privileged users to be able to run `ping`, then take it away from them. The reason ping is set-UID is so that non-privileged users can use it and the reason it is an executable and not a library that is that way is because all Unixes have set-UID binaries while many don't have set-UID libraries. If a user has a trojan `ping` in their $PATH, then that is problem even without a Perl module involved. Just find "ping" in $ENV{PATH} and use it if they request that kind of ping. A module is the perfect place to collect the heuristics needed to interpret the output of `ping` on different systems. There are already modules that do this for other commands such as `ps`. It makes sense to me to have a Net::Ping::External (since it will get a bit complex) and just have Net::Ping know how to use that module. Perl is very good at heuristics so I don't think this will be a huge problem. 3) As mentioned, this would just use the best method available and wouldn't have to time out multiple times. I'd also make it the default "protocol" so "just doing a ping" usually works without the script writer having to worry about "am I being run as root?", "what operating system is this", etc. Again, a module is a good place to collect these decisions. 4) Non-blocking connect doesn't work under Win32, BTW. The SO_RCVTIMEO sounds interesting. I have my doubts that it works for connect [just based on the name] which is all that we need it for, but it certainly sounds worth looking into. I find it interesting that even Perl's Socket modules use alarm to timeout connect (even when they use other methods for timing out other calls). 5) Well, I wouldn't choose fork for this. For UDP and ICMP you can create a single socket, send out a bunch of packets and see what comes back. For TCP, on systems where non-blocking connect works, you can create a bunch of sockets, start connects on each and use select to wait to see what happens. That is the kind of stuff that makes sense to encapsulate in a module. - tye (but my friends call me "Tye")In reply to (tye)Re2: A proposal for improvements to Net::Ping
by tye
|
|