CSYSMAS@OAC.UCLA.EDU (Michael Stein) (10/13/89)
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?).
awaldfog@wellfleet.com (Asher Waldfogel) (10/13/89)
It is certainly true that "global" broadcasts don't scale well. But broadcasts (and multicasts) are very useful within "local" LAN domains. I also agree with the direction of your idea for rwho services. But I think the real bug in scaling is building a bridged network with 30K+ nodes. To scale to that size you need to route. More importantly, I'm not sure we should worry too much about "local" protocols such as rwho scaling into overgrown bridged environments. Asher Waldfogel Wellfleet Communications