From: lowry@watson.ibm.com (Andy Lowry)
Subject: Client-Server paradigm adequate for distributed computing? (Was: Re: Accepting sequences?
Date: Tue, 6 Oct 1992 21:22:51 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
	<LOWRY.92Oct4133535@rotor.watson.ibm.com>
	<1992Oct05.173636.93164@Cookie.secapl.com>
Organization: IBM T.J. Watson Research Center
Followup-To: comp.client-server

[Note the Followup-To header... I think this discussion is moving away
from anything of general interest to comp.theory readers.]

In article <1992Oct05.173636.93164@Cookie.secapl.com> frank@Cookie.secapl.com (Frank Adams) writes:
 > In article <LOWRY.92Oct4133535@rotor.watson.ibm.com> lowry@watson.ibm.com (Andy Lowry) writes:
 > >In article <1992Oct02.165008.37497@Cookie.secapl.com> frank@Cookie.secapl.com (Frank Adams) writes:
 > > > In any event, programs which run indefinitely do not generally do
 > > > *a* computation; instead they act as servers, performing and
 > > > completing multiple computations.
 > >
 > >This is a fairly limiting view of long-lived programs.  It may be a
 > >fairly common view currently, partly due to the success to date of the
 > >client-server paradigm for distributed computing.  But I think this is
 > >a case of a partial solution (to the problem of developing distributed
 > >systems) turning around and redefining the problem by obscuring the
 > >parts of it that it doesn't address.  People will have a need for
 > >long-lived, largely autonomous programs that have varied, dynamic
 > >interactions with other programs.  Many of these programs will act as
 > >servers, but many will not.  Examples are easily had by considering
 > >programs that carry on long-term intractions with the physical
 > >environment, like online market analysis programs.  The state of such
 > >a program at any given point in time is determined by its entire
 > >history of interactions, not by some recently initiated client
 > >interaction.  It's intended to run "forever," but it cannot be
 > >characterized as "completing multiple computations."
 > 
 > Widen your definition of "client"; the interaction with the feed
 > from the market is as much a client interaction as the interaction
 > with a person on a workstation, from the point of view of the
 > program.

Maybe, maybe not.  Maybe I need to ignore the source for a while,
unbeknownst to it.  Maybe I need to stick an active filter between it
and me, again unbeknownst to the source.  Or maybe somebody else needs
to add such a filter, unbeknownst to either of us.  Of course you can
widen the notion of "client" and "server" to fit whatever you want.
My point is that the current, common notions, around which most of the
tools to support distributed computing are being built, are limiting.

 > Yes, the program has a database, but this is not unusual.  

It's also not very relevant (and please, let's also not perpetuate the
myth that state = database).

 > And it had better keep sufficient state information in the database
 > that it can start up again from it, because we can't expect
 > computers that *never* go down anytime soon.

This is also not very relevant, but I'll point out that it assumes
that it's important that the program not lose state if it crashes.
This is not always the case.

 > Admittedly, a program which spent all its time between interactions doing
 > computations would be a somewhat different animal; but I am not familiar
 > with any that actually do this.

Is this because no such programs are conceivable, or because not very
many exist, given the difficulty of creating them with client-server
based software tools.  It would seem to me that an industrial
monitoring system could easily be imagined that tracks lots of sensors
>from all over the plant.  Input arrives asynchronously, and between
inputs, this monitoring system is constantly poring over the data
looking for anomalies.  The quality of the analysis depends on the
amount of "think time" the system gets between input events, but it
can never get too much.

 > The paradigm is: get input, compute something, write to the
 > database; get request for output, read database, compute solution,
 > output it.

Make that "A paradigm".  How about another: get a request; delegate
that particular request to another process that will see it as a
normal incoming request, but set up a new filter process to monitor
the return data and report a summary back to you asynchronously;
capture some data from the market feed and broadcast it asynchronously
to a number of interested clients, many by way of transparent
intermediary active filters, and perhaps one of which is the
originator of the call you just delegated; do some local computing and
send some updates asynchronously to interested processes; get another
request and stash it away for later (the originator of that request is
meanwhile blocked); get a third request and delegate it, this time
without a watchdog process (so you're completly disconnected from this
request at this point); get a fourth request and process it, which
involves various interactions with a pool of "advisors"; revisit the
second request you got, process it, and return results, thereby
unblocking the request originator; return results to the originator of
the fourth request; get the asynchronous report of the first request
>from the filter process you set up earlier; notice that you're
becoming bogged down and need to distribute your workload; create a
new process on another machine to take some of the load, and set up a
"splitter" on your incoming request port to parcel out incoming
requests; establish other interaction channels with your new partner
process so you can coordinate for whatever consistency is required
(all this unbeknownst to any process capable of sending requests on
this port); etc.

Can you point to some software technology that's going to *help* me
create this beast and is based on the client-server paradigm?  I can
point to such technology that's based on a more flexible view of
distributed computing.
--
Andy Lowry, lowry@watson.ibm.com, (914) 784-7925
IBM Research, P.O. Box 704, Yorktown Heights, NY  10598
Newsgroups: comp.theory