Blocking port 7 from latency probes...

[Skip Montanaro]

    Jeff> I am all in favor of latency testing throughout the Internet. In
    Jeff> fact, I have a box on my network now that is dedicated as a probe
    Jeff> for a project on Internet2. Why not try to marshall support for a
    Jeff> standards based probe array instead of just scanning what ever
    Jeff> will answer. Is that to much to ask?

(Does this really have anything to do with bind?)

I won't attempt to justify DoubleClick's use of port 7 or their attitude
about it.  I will point out how/why I use port 7 as a "ping" port.

I developed and maintain a distributed concert database.  All communications
between servers is done using XML-RPC (http://www.xmlrpc.com/ for the
curious).  The servers are not multi-threaded, so I can't have them stall
while trying to talk to each other because they won't be able to respond to
queries.  Consequently, I needed a simple, fast way to decide if a
downstream server was up before making a remote procedure call.  UDP (not
TCP) to port 7 served nicely for a few reasons:

    1. I felt it would be the fastest way to check if a remote server was
       up.

    2. I didn't have to learn how to generate and send ICMP echo packets
       from Python (my chosen application language in this case).

    3. I felt that since on most Unixen port 7 echo code seems to be built
       directly into inetd, not only would I get good performance, I'd be
       accessing a piece of server code that was fairly well beat upon and
       debugged already.  The alternative would be to pick an arbitrary
       high-numbered port and hang a homebrewed UDP echo server off of that.
       Consequently, enabling it on my servers probably wasn't going to
       increase my vulnerability to attack.

Skip Montanaro | http://www.mojam.com/
skip at mojam.com | http://www.musi-cal.com/
847-971-7098   | Python: Programming the way Guido indented...