Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!think!ames!apple!motcsd!hpda!hpcupt1!hpisod2!dhepner
From: dhepner@hpisod2.HP.COM (Dan Hepner)
Newsgroups: comp.databases
Subject: Re: Performance Data (was Re: Client/Server processes and implementations)
Message-ID: <13520007@hpisod2.HP.COM>
Date: 2 Dec 89 00:25:26 GMT
References: <7169@sybase.sybase.com>
Organization: Hewlett Packard, Cupertino
Lines: 82

From: hargrove@harlie.sgi.com (Mark Hargrove)
> 
>    >(and in the extreme (and not at all impractical) case, you run each 
>    > client and each server on its own machine).  This model is simple, 
>    > elegant, and fundamentally right.
> 
>    This would require basically a 50-50 split of the workload between
>    the client and server. A practical assumption? 

> Have you read Mike Harris' recent postings?  He gives
> good examples of what client-server is all about.  I think *you're*
> drifting in the direction of distributed processing, where a single
> problem is broken up and shared by several machines.  This is NOT what
> we're talking about here.

Why would "you run each client and each server on its own machine" 
if not to break a single problem up to be shared by more than one
machine?  Indeed, I'm talking about distributed processing, but I 
disagree with your protest that I'm alone. Without a distributed 
processing goal, what is the point of a C/S architecture?

[Mark points out miscommunication]

Clearly it's pointless to dispute the definitions of words, so let's
get to some meat.  Here's my claim:

1) If I need to do a set of several tasks, this becomes my "problem". 
   Now I can probably break this problem easily into Mark's "single 
   problems", or tasks which share no common resource. I 
   can place each of those problem solutions on a different machine,
   and establish a communications network allowing me access to each,
   from my terminal, or whatever I have on my desk.  I may even have
   intelligence on my desk to translate my high level human requests 
   into a complex series of interaction with those solution machines.

   If you'd like me to stop here, and call that the fulfillment of a C/S 
   architecture, some might contest how important your definition of C/S was.
   You might also call this distributed processing, but some might
   contest how important your definition of distributed processing was.

2) We may not agree on whether we've been discussing distributed processing,
   but maybe we'll agree on the desireability of distributed processing, 
   even to the extent of 
            Mike Harris> Imagine a world where everything was a PC.

3) The essense of distributed processing is, to use Mark's
   terminology, "breaking single problems into into parts which 
   can be worked on by different machines", where a "single problem"
   implies a shared resource, e.g. a database.

4) The division of any "single problem" into a C/S allows for
   distribution, by allowing the client and server to be on
   different machines (serial connected, ethernet if you like).
   This I claim is the non-trivial definition of C/S, and indeed
   the primary purpose of doing so.  This definition is certainly
   meaningful across an arbitrary number of levels of abstraction.

5) The value of that C/S distribution will be proportional to the
   percentage of the problem cost, as typically measured by
   CPU cycles, which is moved into the client.  Dividing a
   problem into 10% client and 90% server isn't all that valuable.
   Doing so across 10 layers of abstraction is demonstrably ridiculous. 
   [Yes, one should consider the security advantages in some C/S 
   divisions to be of some value]

   On the other hand, dividing a problem into 90% client, and 
   10% server would yield an immediate potential for a 10X improvement
   using equal technology hardware.  And doing so across 10 layers
   of abstraction would achieve the distributed dream: a world of
   PCs.  This dream is what drives statements which describe C/S 
   as  "simple, elegant, and fundamentally right".

6) Unfortunately, the state of the art C/S divisions actually available 
   from vendors usually end up without much work being done by the
   client, and many such products IMHO would be better off without
   having bothered.  Hopefully this will change with time.  If you have 
   any notion of a world of only PCs, you gotta hope so too.

Dan Hepner
dhepner@hpda.hp.com

Disclaimer: HP may well disagree with every word of this opinion.


Brought to you by Super Global Mega Corp .com