Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!OAC.UCLA.EDU!CSYSMAS
From: CSYSMAS@OAC.UCLA.EDU (Michael Stein)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: rwho'ing (and other broadcasting...)
Message-ID: <8910130923.AA21266@ucbvax.Berkeley.EDU>
Date: 13 Oct 89 08:10:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 27

First I have to admit that I'm scared of broadcasts, especially
ones which are automatic.  I keep seeing a "bridged" campus
wide LAN (token ring, eventually FDDI?) with 30k+ machines.

If each has a Rwhod which outputs 1 broadcast UDP packet
every 30 seconds then there will be 1000 packets/seconds
which EVERY host will receive and have to deal with.

  ** as far as I can see BROADCAST's don't scale up **
   (can you see a world wide network doing this too?)

I kind of like the proposal by Jeff Michaud:

>   A more efficient method all around would be to have a dedicated      system
>   act as a "remote who" server.  On a timer the server system (le     ts call
>   this one the master server) will send out a udp broadcast adver     tising
>   itself as a "remote who" server.  Hosts that want to advertise      who's
>   logged on the system (call these slave servers) send the info d     irectly
>   to the "remote who" server.   Clients which want info on whos l     ogged
>   in on the network asks the local slave server (who knows who th     e master
>   server is) who in turns asks the master server (or the slave se     rver
>   can store the master servers address/port away where clients ca     n use
>   it to request the info directly from the master server).

I'd only make one change -- advertise the server via some
DNS like mechanism, no broadcasts at all... (Perhaps this requires
X.500?).