netselect 0.3
=============
This is netselect, an ultrafast intelligent parallelizing binary-search
implementation of "ping."
Now stop laughing and pay attention.
netselect determines several facts about all of the hosts given on the
command line, much faster you would if you manually tried to use ping and
traceroute. For example, if I type:
netselect -vv ftp.fceia.unr.edu.ar ftp.kulnet.kuleuven.ac.be \
ftp.cdrom.com ftp.debian.org ftp.de.debian.org
It tells me this:
ftp.fceia.unr.edu.ar 2792 ms 23 hops 100% ok ( 1/ 1) [ 9213]
ftp.kulnet.kuleuven.ac.be 9999 ms 30 hops 0% ok
ftp.cdrom.com 94 ms 8 hops 100% ok (10/10) [ 169]
ftp.debian.org 46 ms 15 hops 100% ok (10/10) [ 115]
ftp.de.debian.org 9999 ms 30 hops 0% ok
115 ftp.debian.org
For each host, it figures out the approximate ping time (though not as
accurately as "ping" does), the number of network "hops" to reach the
target, and the percentage of ping requests that got through successfully.
The value in brackets is the "score" of each operational host based on these
values. A lower score is better. The last line shows the server with the
best score. If we had not used '-vv' on the command line, only this last
line would have been printed.
Note that for ftp.kulnet.kuleuven.ac.be and ftp.de.debian.org in this case,
nothing got through at all. That indicates that either the host doesn't
exist, or it is down.
For a bigger example, try netselect-apt to build your own sources.list for apt
with the (possibily) fastest debian mirror.
But Why?
========
Why do I want to know about my ping times to computers in Belgium? Well,
the main reason for netselect -- and its name gives you a hint -- is to help
choose the "best" server for you from among a (possibly very large) list.
Starting with version 0.2, netselect can make these decisions for you using
its scoring mechanism. If you want, however, you can still pass the raw
results and score the servers as you like. Try this, for example:
netselect -vv -s 0 $(cat <your_list_of_sites>)
The "-s 0" option disables printing of scores at the bottom of the list, and
"-vv" enables printing of the statistics.
How does it work?
=================
First:
- decode each hostname into an IP address, and stores each IP address into
a table. In netselect 0.2, this code was rewritten to resolve hostnames
much more quickly than before.
Now for all hosts at once:
- start firing UDP packets with "random-guess" TTL values, much like
traceroute does. Actually, the code for this is derived from traceroute.
- if an "ICMP TTL Expired" message comes back, then the TTL was too low:
the host is farther away than that. Increase TTL next time. Otherwise,
a "Port Unreachable" message comes back, meaning the TTL was large
enough. Try a smaller one. We do this until we narrow down the TTL.
(This is where the "binary search" comes in.)
- Meanwhile, collect timing statistics for all packets that reached the
host. Packets that don't come back are considered lost.
When all the hosts have had their TTL values narrowed down, and the "-t"
minimum tries have expired, we're done. Close the sockets and dump
the statistics to stdout.
Command-line Options
====================
Not much right now.
-v -- verbose mode. Displays nameserver resolution messages to
stderr. You probably want this so that you don't get
bored waiting for a hundred name resolutions to finish.
-vv -- very verbose mode. Displays nameserver resolution and
statistics (not just scores) to stderr and stdout.
-vvv -- very very verbose mode. Everything -vv prints, plus
print every packet received as it happens. Good for
debugging or trying to figure out how it works.
-vvvv -- very very very verbose mode. Everything -vvv prints,
plus a trace of all packets sent.
-m # -- maximum ttl. Don't accept hosts with more hops than
this.
-t # -- make sure at least 50% of the hosts get tested with this
many packets. The more packets you use, the more
accurate the results... and the longer it takes to run.
The default is 10, which is usually okay.
-s # -- print this many "top-scoring" servers at the end of
the list. "-s 0" disables printing of high scores.
The Future
==========
Here are some possible improvements:
- try to estimate line bandwidth somehow. The 'bing' program does
it using two different ping packet sizes.
- try to improve 'ping time' estimate. It's a problem right now
because netselect writes a lot of packets in a quick stream (for
speed reasons). It's fair to each host, though: they all put up
with an equal amount of lag :)
This program is highly experimental. Please let me know what you think.
- Avery Pennarun
<[email protected]>
