From: bantha.decnet.lockheed.com!young
Subject: The Distributed Problem
Reply-To: young@bantha.decnet.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Wed, 2 Sep 92 16:00:22 GMT

In article <1992Sep1.212344.7089@informix.com>, johng@informix.com (John Galloway) writes:
>In article <1992Aug31.160529.8597@iscnvx.lmsc.lockheed.com> young@bantha.decnet.lockheed.com writes:
>>In article <p8bpe4o@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>>>In article <1992Aug30.164226.2031@iscnvx.lmsc.lockheed.com>, bantha.decnet.lockheed.com!young writes:
>>>> This newsgroup continues to debate the interface between TCP/IP routers
>>>> and ATM. Must be an important application.
>>>> 
>>>> Now here is another problem which ATM might solve.
>>>> 
>>>> Imagine that an account executive wants to read into his spread sheet the
>>>> entire daily summary of mail orders spread over a number of distributed
>>>> offices.  Thus, he wants to extract a particular file located in each of
>>>> a large set of desktop machines.  
>>>> 
>>>
>>>Are you sure that ATM is an obvious part of a solution to this kind of
>>>problem?
>>>
>>>Doesn't this sound more like an application for a multicast based
>>>"distributed" application?  Perhaps some kind of multicast remote
>>>procedure call?  Using UDP/IP multicast?
>>>
>>>Vernon Schryver,  vjs@sgi.com
>>Yes, Yes the solution needs some kind of exploratory, application specific,
>>protocol which can search out and find, then bind those desktops in
>>a spanning tree, and then have the capacity to extract file data from
>>each node, all in a parallel fashion.
>
>"extracting a particular file located in each of a large set of desktop
>machines" is a very naive view of a distributed database, which is what
>you are describing in this example.  In such a case ensuring the consistency
>and accuracy of the database (i.e. dealing with net link going down, or
>a system going down, or a disk failing, or a local users screwing up, and
>with concurnet updates and multiple copies of the data, and ....)
>will far outweigh (by an order of magnitude at least, if not several) the
>network overhead even in current ether-LAN's, let alone in various
>"networks of the future".
>
>So in this example, the system looking for this distribued file or data
>is very likely not just beginning to do so when the request is made, but
>has already been set up as part of the distributed db system.  Indeed
>if some stations are reached via ATM and are not in contact at this poiont,
>then calls will have to be placed.  But again, I would suspect that the
>time spent on each system findings its piece of the data, and the time spent
>on the requesting node assembling it all, will dwarf the network overhead
>on any of the nets being discussed here.  or so it seems to me.
>	-jrg
>-- 
>internet    jrg@galloway.sj.ca.us  John R. Galloway, Jr  795 Beaver Creek Way
>applelink   D3413                  CEO...receptionist    San Jose, CA   95133
>                                   Galloway Research     (408) 259-2490

Ok so the debate is that overhead associated with:

1) A single intelligent messaging layer which operates over the ATM 
switches for:

   data integrety, route/host  discoverylink failure, nodes down and data 
re-formatting.
B 
Versus the overhead in using:

2) Existing call set up structure, keeping a map of all host addresses,
performing some sort of preliminary data reformating to put the stuff into
a data base format.  

Solution 1 involves a single intelligent messaging layer, operating over
the ATM network and desktops, moving all the call set up procedures into a 
recursive, spatial route discovery capability, re-formatting the data in an 
application specific manner (or activiting local daemons in the local nodes 
to do same), collecting data as needed to existing applications, operating 
in a parallel distributed manner, on command of the user.

Solution 2 is the current layered technology, with the addition of 
a new call set up procedure, a mapping or data base structure for all the 
host addresses, the attendant mapping of personal functions to host machines
(to allow data acquisition), and a sequence of structured operations.

One item I forgot to mention, the customer pays exponentially more for the 
fewest number of layers he has to manage in his enterprise.  Each layer of 
software requires an extra training and management system.

Since Connection Machine Inc claims to have a software paradigm for the direct
software engineering of an array of processors, what is it we do differently 
which prevents us from drawing on that model?
Newsgroups: comp.dcom.cell-relay