--- AnyEvent-FastPing/FastPing.pm	2011/02/02 19:26:45	1.13
+++ AnyEvent-FastPing/FastPing.pm	2011/02/02 20:04:17	1.14
@@ -12,8 +12,9 @@
 REQUEST packets as quickly as possible to a large number of hosts
 (thousands to millions).
 
-It employs a sending thread and is fully event-driven (using AnyEvent), so
-you have to run an event model supported by AnyEvent to use this module.
+It employs a separate thread and is fully event-driven (using AnyEvent),
+so you have to run an event model supported by AnyEvent to use this
+module.
 
 =head1 FUNCTIONS
 
@@ -103,13 +104,13 @@
 idle callback to trigger.
 
 Performance: On my 2 GHz Opteron system with a pretty average nvidia
-gigabit network card I can ping around 60k to 200k adresses per second,
+gigabit network card I can ping around 60k to 200k addresses per second,
 depending on routing decisions.
 
 Example: ping 10.0.0.1-10.0.0.15 with at most 100 packets/s, and
 11.0.0.1-11.0.255.255 with at most 1000 packets/s. Also ping the IPv6
 loopback address 5 times as fast as possible. Do not, however, exceed 1000
-packets/s overall. Dump each received reply:
+packets/s overall. Also dump each received reply.
 
    use AnyEvent::Socket;
    use AnyEvent::FastPing;
@@ -146,8 +147,8 @@
 =item $pinger = new AnyEvent::FastPing
 
 Creates a new pinger - right now there can be at most C<65536> pingers in
-a process, although that limit might change to somethind drastically lower
-- you should be stringy with your pinger objects.
+a process, although that limit might change to something drastically lower
+- you should be stingy with your pinger objects.
 
 =cut
 
@@ -166,7 +167,7 @@
 
 =item $pinger->on_recv ($callback->([[$host, $rtt], ...]))
 
-Registeres a callback to be called for ping replies. If no callback has
+Registers a callback to be called for ping replies. If no callback has
 been registered than ping replies will be ignored, otherwise this module
 calculates the round trip time, in seconds, for each reply and calls this
 callback.
@@ -174,7 +175,7 @@
 The callback receives a single argument, which is an array reference
 with an entry for each reply packet (the replies will be batched for
 efficiency). Each member in the array reference is again an array
-reference with exactly two members: the binary host addresss (4 octets for
+reference with exactly two members: the binary host address (4 octets for
 IPv4, 16 for IPv6) and the approximate round trip time, in seconds.
 
 The replies will be passed to the callback as soon as they arrive, and
@@ -198,7 +199,7 @@
       for (@{ $_[0] }) {
          printf "%s %g\n", (AnyEvent::Socket::format_address $_->[0]), $_->[1];
       }
-   };
+   });
 
 Example: a single ping reply with payload of 1 from C<::1> gets passed
 like this:
@@ -239,10 +240,10 @@
 =item $pinger->interval ($seconds)
 
 Configures the minimum interval between packet sends for this pinger - the
-pinger will not send packets faster than this rate (or atcually 1 / rate),
+pinger will not send packets faster than this rate (or actually 1 / rate),
 even if individual ranges have a lower interval.
 
-A value of C<0> selects the fastests possible speed (currently no faster
+A value of C<0> selects the fastest possible speed (currently no faster
 than 1_000_000 packets/s).
 
 =item $pinger->max_rtt ($seconds)
@@ -250,11 +251,11 @@
 If your idle callback were called instantly after all ranges were
 exhausted and you destroyed the object inside (which is common), then
 there would be no chance to receive some replies, as there would be no
-time fo the packet to travel over the network.
+time of the packet to travel over the network.
 
 This can be fixed by starting a timer in the idle callback, or more simply
 by selecting a suitable C<max_rtt> value, which should be the maximum time
-you allow a ping packet to travel to its destinazion and back.
+you allow a ping packet to travel to its destination and back.
 
 The pinger thread automatically waits for this amount of time before becoming idle.
 
@@ -272,7 +273,7 @@
 C<Socket6::inet_pton> or any other method that you like :)
 
 The algorithm to select the next address is O(log n) on the number of
-ranges, so even a large number of ranges (many thousands) is managable.
+ranges, so even a large number of ranges (many thousands) is manageable.
 
 No storage is allocated per address.