/sys/doc/ Documentation archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Distributed Processing and Client/Server computing

>> Sorry, I **firmly** and **strongly** believe in NOT centralizing processing.
> This is the dying gasp of what I call "mainframe think".

>You are contradicting yourself then. The ultimate in centralized
processing is the PC where all the apps and files are local. 

Yes, if you use only a single system and a single copy of the database, with no 
sharing of it.  BUT that's not what I'm talking about.

>Is that what you believe in? 

No, of course not.

>I am not talking about a centralized CPU somewhere
that everyone connects to, a la, mainframe. I am talking network -- pick
your favorite -- MCI, ATT, INTERNET, where there are "public" CPUs that
I use for cycles, when I don't have enough on my NC. 

That's relatively ludicrous, given that a relatively high-end Pentium or Pentium 
Pro is already faster than Cray supercomputers were a very few years ago.  Once 
you put several people onto these 'public' CPUs, they end up being slower than a 
very reasonable dedicated local processor.  And this is precisely why 
timesharing isn't the great idea it once looked like.  It used to be that you 
got MORE for your money, the bigger and more expensive your machine.  (This was 
called Grosch's Law, after Herb Grosch who was an influential columnist of the 
era at Computerworld, and president of the ACM).  However, today, the "law" is 
quite the opposite:  you can get almost as much computing power as you want, and 
nearly for free... as long as you don't insist on it being all in the same 
place!

>This is totally different from "mainframe" think. In fact, the whole network is 
my oyster, since you can have pieces of the app running on several
different boxes and sets of specialized boxes that are optimized for
certain activities (e.g., serving video streams, or bridging/conference
of audio streams.

And if you're really DISTRIBUTING your processing across NUMEROUS CPUs, then we 
disagree less than you thought.  What I don't like is people with a substantial 
(sufficient) local computing capacity who then try to ship the work off to 
another SHARED system somewhere else, which ends up getting bogged down trying 
to serve lots of other users.

>One advantage is that a box is not a single point of failure. If A
fails, we just use B. If A is overloaded, we defer to C, etc. I am
curious what you DO believe in then, cause I suspect that it isn't very
different from what I am thinking about. 

What I like the most is a host-free LAN offering the ability to distribute a 
large processing job across many CPUs... the idea being to cluster as much 
processing power as possible around the company's crucial database... and to do 
everything possible to maximize that fanout.

>We use a population of
resources that can communicate and harness them for the benefit of the
population of the users. In that sense its like "mainframe", I multiplex
the resources across a population of users. 

Multiplexing is fine, as long as the whole thing doesn't smack of timesharing.  
For example, I think it's stupid in the extreme to use a powerful PC as a "smart 
terminal" running (say) X-Windows, while you offload all the processing load 
onto a timeshared (and generally hugely expensive) "mainframe" somewhere else.  
If you have a nontrivial number of users, the aggregate computing power 
possessed by the "terminals" probably greatly exceeds that of the "mainframe".

>The big difference is the communications speed and the lack of a single point 
of failure.

And that's another reason to avoid typical client/server architectures, where 
the server is precisely such a 'single point of failure'.

>I really would like to appreciate what you find wrong with the notion of
network computing.

I'm not opposed to network computing (and this shouldn't really come as a 
surprise, since I was the guy who conceived, designed, and wrote the system 
software for the first commercially successful LAN).  What I don't like is 
timesharing, and trying to pile up all kinds of processing load (that OUGHT to 
be distributed) on a central "cpu server".

Does that clear up my position??

Gordon Peterson
http://www.computek.net/public/gep2/