What to do about rwhod

Jeff Mogul (mogul@su-navajo.arpa)
24 Feb 1986 1241-PST (Monday)

    P.S. Just a thought, perhaps the ultimate solution will be smart
    interfaces that can be told a little about what packets the host
    is interested in and drop all others, tho again ultimately the
    problem will be the bandwidth of the cable. sigh.

I.e., multicast, as other people have suggested, would be the ideal
solution to the rwhod problem (and similar ones, such as
broadcast-based routing protocols.) Unfortunately, it's not clear how
easy it will be to implement multicast support in 4.2 (and successors)
even if someone comes up with a good IP multicast spec.

Alternatively, maybe rwho/d could be run on a "lazy-evaluation" basis.
Change the rwhod servers so that the only time they broadcast status
packets is when they start up. When someone types "ruptime" or "rwho",
if the information stored at the local host is more than, say, 5
minutes out of date, an "rwho status request" packet is broadcast; the
rwhod servers on the net respond with packets directed at the
requesting host. This means that some packets are broadcast, but only
when the information is both wanted and hasn't been updated recently;
the number of broadcasts in the worst case is no more than currently,
and in the best case is epsilon more than zero.

The disadvantage of this scheme is that you no longer can be sure just
how long a catatonic host has been down, unless people having been
requesting updates fairly often. There are obvious algorithms to
maintain this sort of information, i.e. use a designated central site
to poll other sites (non-broadcast) at reasonable intervals, and use
broadcasts only to join the group or recover from the loss of a central

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:04 GMT