view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

	- fix a bug in the checksumming algorithm.

2.01  Sun Feb  6 01:23:25 CET 2011
	- add_hosts now allows mixed ipv4 and ipv6 addresses.
	- netbsd and solaris lack PTHREAD_STACK_MIN. sigh.

2.0   Wed Feb  2 21:20:11 CET 2011
	- use completely different object-oriented API. more complex, but
          also much more flexible.
        - support host lists in addition to ranges.
        - support per-pinger receive callbacks, no more global callback stuff.
	- no longer embed floating point values in packet, to avoid relying
          on isnormal.
        - use slightly faster ipv4 checksumming function.
        - better cope with high overload conditions by using exponential backoff.
        - add missing - sigh - common::sense dependency.

1.15  Sun Jan 30 00:55:10 CET 2011
	- famous last words: final 1.x API release.
        - bin/fastping didn't support ipv4 anymore, due to a thinko :/.

FastPing.pm  view on Meta::CPAN

=item AnyEvent::FastPing::icmp6_pktsize

Like AnyEvent::FastPing::icmp4_pktsize, but for IPv6.

=back

=head1 THE AnyEvent::FastPing CLASS

The AnyEvent::FastPing class represents a single "pinger". A "pinger"
comes with its own thread to send packets in the background, a rate-limit
machinery and separate idle/receive callbacks.

The recommended workflow (there are others) is this: 1. create a new
AnyEvent::FastPing object 2. configure the address lists and ranges to
ping, also configure an idle callback and optionally a receive callback
3. C<start> the pinger.

When the pinger has finished pinging all the configured addresses it will
call the idle callback.

The pinging process works like this: every range has a minimum interval

README  view on Meta::CPAN

                                    * (1000 / 8 / AnyEvent::FastPing::icmp4_pktsize);

        etc.

    AnyEvent::FastPing::icmp6_pktsize
        Like AnyEvent::FastPing::icmp4_pktsize, but for IPv6.

THE AnyEvent::FastPing CLASS
    The AnyEvent::FastPing class represents a single "pinger". A "pinger"
    comes with its own thread to send packets in the background, a
    rate-limit machinery and separate idle/receive callbacks.

    The recommended workflow (there are others) is this: 1. create a new
    AnyEvent::FastPing object 2. configure the address lists and ranges to
    ping, also configure an idle callback and optionally a receive callback
    3. "start" the pinger.

    When the pinger has finished pinging all the configured addresses it
    will call the idle callback.

    The pinging process works like this: every range has a minimum interval