Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!RICHTER.MIT.EDU!krowitz
From: krowitz@RICHTER.MIT.EDU (David Krowitz)
Newsgroups: comp.sys.apollo
Subject: Re:  RGYD at 10.2
Message-ID: <9007202155.AA21141@richter.mit.edu>
Date: 20 Jul 90 21:55:02 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 40

There are a couple of reasons to run more than one copy of /etc/ncs/glbd (this
applies to /etc/rgyd, too). The first is for overall network reliability. If
you only have one copy of the NCS server running and that node goes down for
any reason, then *no* applications which use NCS services can find each other
unless they just happen by accident to be running on the same node. If you have
more than one copy of the global server, then the local broker on your node
can usually find one of the alternate global brokers. The second reason is
for distributing the workload. This is only really needed if you have a lot
of NCS applications running on your net (either a lot of nodes each running
a few applications or a few nodes running a lot of applications). Note that
login/logout (which use rgyd, which in turn uses NCS), printing via either
prf or lpr, and debugging with DDE are all common activities which use NCS
services. So do ftp and telnet (login/logout), any Unix program which reads
/etc/passwd or /etc/group (which are special objects whose type-manager call
rgyd to extract the registry info), etc. 

The big problem is that since NCS services and registry services are now
part of the low-level system services they *MUST* be extremely robust or
the entire system fails ... and they aren't all that reliable. 

As for the clocks ... this is another reason why I hate Unix ... reliable
system operation requires yet another service which is not provided by
the OS. /etc/timed can alledgedly be used to keep the clocks consistant,
but it's just another server which I've got to configure and run on every
single node in the network, and of course it's built on top of TCP services
so that it fails when TCP fails -- and TCP services can be made to fail
in so many ways which are completely unrelated to an actually network 
failure (ie. cabling, networking card, host down, network jammed, etc)
that it's frightening. By contrast, DDS services only fail when the network
fails, and they usually recover then the network recovers. TCP based
services general require that the individual servers be killed and
restarted. 


 -- David Krowitz

krowitz@richter.mit.edu   (18.83.0.109)
krowitz%richter.mit.edu@eddie.mit.edu
krowitz%richter.mit.edu@mitvma.bitnet
(in order of decreasing preference)