Not sure about the license. Hope this is useful to someone.
As an aside: anyone have a port of Net::Ping they are willing to share?
I’m
trying to convert some code (and colleagues!) to Ruby and am running
into the
“missing libraries” issue…
As an aside: anyone have a port of Net::Ping they are willing to share? I’m
trying to convert some code (and colleagues!) to Ruby and am running into the
“missing libraries” issue…
Check the RAA (and Rubyforge).
For ping, there is ‘ping’ in the standard library, and ‘net/ping’ on the
RAA (‘gem install net-ping’).
Pat Eyler wrote in May about pushing an ICMP-capable version of net/ping
into the standard library for 1.8.6.
Pat Eyler wrote in May about pushing an ICMP-capable version of net/ping
into the standard library for 1.8.6.
Cheers,
Dave
Indeed, Pat talked to me about possibly including net-ping in the
standard lib, though it needs a PingICMP class. It could probably
stand a bit of reorganization, too.
In fact, I still have some code laying around that Sean C. sent
to me a long time ago. Maybe it’s time to revisit that.
For ping, there is ‘ping’ in the standard library, and ‘net/ping’ on the
RAA (‘gem install net-ping’).
ugh! I hate ping.
I’ve actually done some work on the code, but it’s in need of some
documentation and a bit more polish. The ICMP ping still needs
to be integrated as well.
I just have more ambition than time, talent, and energy.
I’ve actually done some work on the code, but it’s in need of some
documentation and a bit more polish. The ICMP ping still needs
to be integrated as well.
I just have more ambition than time, talent, and energy.
It sounds simple enough for a Ruby Q… Then we’d have not two, but a
dozen versions, possibly including a Net::Ping-interfaced one for Jos!
Indeed, Pat talked to me about possibly including net-ping in the
dozen versions, possibly including a Net::Ping-interfaced one for Jos!
I’m a huge fan of using the Ruby Q. to improve libraries like
this. I’m a Ping Dummy, so you guys put your heads together and
write up something that explains the goals and if I can understand
them, we’ve got a winner.
It takes a lot less time, talent, and energy to define the problem
well enough to get help from the whole community and the results
never cease to dazzle me…
For ping, there is ‘ping’ in the standard library, and ‘net/ping’ on the
RAA (‘gem install net-ping’).
I’m aware of those but they lack some features the Perl version has. Notably
ICMP support and returning timing information.
Well, there is PingExternal for ICMP support.
Seriously, though, both would be good additions.
It would also be nice for there to be a single Net::Ping class, just like the
Perl version provides, wrapping/hiding the specialized classes. That seems
like an easy addition.
The API was modelled after the current ping.rb in the standard library
to try to keep things consistant and more portable for anyone switching
from ping.rb to my net-ping module. A factory pattern should be doable
if that’s what folks want. In practice, however, I don’t see it as a
major issue, and probably not worth the API breakage.
On Wed, Nov 29, 2006 at 05:35:13PM +0900, Dave B. wrote:
Hi,
As an aside: anyone have a port of Net::Ping they are willing to share? I’m
trying to convert some code (and colleagues!) to Ruby and am running into the
“missing libraries” issue…
Check the RAA (and Rubyforge).
For ping, there is ‘ping’ in the standard library, and ‘net/ping’ on the
RAA (‘gem install net-ping’).
I’m aware of those but they lack some features the Perl version has.
Notably
ICMP support and returning timing information.
It would also be nice for there to be a single Net::Ping class, just
like the
Perl version provides, wrapping/hiding the specialized classes. That
seems
like an easy addition.
Pat Eyler wrote in May about pushing an ICMP-capable version of net/ping
into the standard library for 1.8.6.
On Fri, Dec 01, 2006 at 12:20:36AM +0900, Daniel B. wrote:
[snip]
I’m aware of those but they lack some features the Perl version has.
Notably
ICMP support and returning timing information.
Well, there is PingExternal for ICMP support.
Seriously, though, both would be good additions.
Indeed.
It would also be nice for there to be a single Net::Ping class, just like
the
Perl version provides, wrapping/hiding the specialized classes. That seems
like an easy addition.
The API was modelled after the current ping.rb in the standard library
to try to keep things consistant and more portable for anyone switching
from ping.rb to my net-ping module. A factory pattern should be doable
if that’s what folks want. In practice, however, I don’t see it as a
major issue, and probably not worth the API breakage.
It eases the transition from Perl, as in my case. If you mean something
like
the following then that would be great:
lizzy:/tmp% cat r
class Ping
def self.create(type, *args)
case type
when :foo
FooPing.new
when :bar
BarPing.new
end
end
end
class FooPing < Ping
def ping(host)
puts "#{self.class}: pinging #{host}"
end
end
class BarPing < Ping
def ping(host)
puts "#{self.class}: pinging #{host}"
end
end
pinger = Ping.create(:bar)
pinger.ping("myhost")
lizzy:/tmp% ruby r
BarPing: pinging myhost
lizzy:/tmp%
Let me know what I can do to help move this along.
On Fri, Dec 01, 2006 at 04:47:05AM +0900, Daniel B. wrote:
Well, you could start by porting the ping_icmp() function from Ping.pm
to Ruby. I started working on it but I got stuck and I need to work on
other things. Below is what I’ve got so far:
I’ve made some progress; see attached. Let me know what you think.
> when :foo
> end
> lizzy:/tmp% ruby r
> BarPing: pinging myhost
> lizzy:/tmp%
>
> Let me know what I can do to help move this along.
>
>
Well, you could start by porting the ping_icmp() function from Ping.pm
to Ruby. I started working on it but I got stuck and I need to work on
other things. Below is what I've got so far:
On Sat, Dec 02, 2006 at 04:54:49AM +0900, Daniel B. wrote:
Jos B. wrote:
Seems to work. Mind if I include with the next release of net-ping
(with acknowledgements, of course).
Of course, thanks Daniel.
The only tweak I would make are to have it return true or false, instead
of 1 or nil.
Good idea. Now, the Perl Net::Ping library returns duration:
($ret, $duration, $ip) = $p->ping($host, $timeout);
In array context, the elapsed time as well as the string form of the
ip
the host resolved to are also returned.
What would be the best way to add that to the Ruby version? Obviously
one
would want all Net::Ping classes to support this. I have a local utility
that
uses this information, which is why I need it.
On Sat, Dec 02, 2006 at 04:54:49AM +0900, Daniel B. wrote:
Jos B. wrote:
Seems to work. Mind if I include with the next release of net-ping
(with acknowledgements, of course).
Of course, thanks Daniel.
Great, thanks.
What would be the best way to add that to the Ruby version? Obviously one
would want all Net::Ping classes to support this. I have a local utility that
uses this information, which is why I need it.
Cheers,
Hm, I’ll have to think about the API. I suppose the most simple
approach is to just add accessors for duration and ip_address (with a
‘nil’ value by default). In practice, then, your code would look like
this:
On Sat, Dec 02, 2006 at 06:03:59AM +0900, Daniel B. wrote:
Hm, I’ll have to think about the API. I suppose the most simple
approach is to just add accessors for duration and ip_address (with a
‘nil’ value by default). In practice, then, your code would look like this:
if p.ping?
puts p.ip_address
puts p.duration
end
How does that look?
I like this much better than the positional API that Perl uses here (“Is
duration the 1st or 2nd return value?”). Plus it makes it easy to add
futher
items down the road without breaking existing code. +1.
True, but one would want the timing measurement to be done as close as
possible around the send and the recvfrom, eliminating the avoidable
overhead
of the method call and setup inside it being included in the duration.
Plus,
having .duration is convenient, no?
And you can get the ip via IPSocket.getaddress(host)
Agreed. That functionality doesn’t belong in this module.
I like this much better than the positional API that Perl uses here (“Is
duration the 1st or 2nd return value?”). Plus it makes it easy to add futher
items down the road without breaking existing code. +1.
Ok, I’ll add those. However, don’t put too much stock in the duration.
Looking at the Perl code, it isn’t much more than this: