🚀 go-pugleaf

In article <1992Oct06.150941.89845@watson.ibm.com> edso@watson.ibm.com (Edward So) writes:
 > If you ask 10 people to define client-server, you get 10++ different
 > answers.  I define client-server as a notion in which party A cooperates
 > with party B to give the illusion that all work is done by party A.
 > So in this context, party A is playing the role of a client, party B,
 > a server.  So, if this notion is applied to computing, a process running
 > somewhere in the network(or locally) provides a service that another
 > process needs to complete its task.  If the two hosts involved are
 > equally capable, they can switch the roles of C/S.  Then they are
 > in a peer-to-peer network.  So, peer-to-peer is not an antithema of
 > client-server, but rather refers to a network topology.
 > TCP/IP, for instance, is a peer-to-peer network, although C/S is the
 > predominant computing paradigm in it.  IBM SNA used to be a non P2P
 > because all nodes were organized in a hierarchical relationship, and
 > dictated the capabilities of each node.  What is the opposite of
 > C/S?  It's centralized, integrated computing.  You may argue that
 > I am looking at only one aspect, and I agree.  What is your definition?

I don't think there has to be any illusion involved.  To me, C-S just
means that there's an entity called a "server" that is willing to take
requests from other entities called "clients" and perform work on
behalf of those requesting clients.  The problem with C-S is that the
distinction of who's doing work for whom isn't always very clear.  And
the problem with the typical software technology you see to support
C-S style computing is that it's typically made fairly easy (but not
nearly easy enough) to play the role of client, but much more
difficult to play the role of server.  There's an asymmetry in the
model, and there's an asymmetry in the implementations.  There appears
to be a view (I've heard it enunciated several times) that servers are
rare, and therefore it's not important to make them easy to create.
The notion seems to be that you create a distributed environment by
designing a small set of "distributed services" and then make it
reasonably easy for programmers to write programs that will make use
of those services.  This is a very close-ended and inflexible view,
and it doesn't help me much when my application doesn't logically fit
the limited C-S model.

I've never thought of peer-to-peer as being a notion related to the
design of the underlying network protocols.  I'm not saying it doesn't
have a reasonable interpretation in that context, but it absolutely
has an interpretation at the applications level.  Peer-to-peer
distributed applications can carry on complex interactions in a highly
dynamic environment (e.g. new processes joining and leaving the
interaction (I'm not just talking about process groups), logical
communication endpoints being copied and passed around among
processes, etc.).  There's no natural distinction where by some
processes are "servers" and others are "clients", even for short
periods of time.  Software technology based on C-S forces programmers
to artificially create such distinctions so they can create their
applications in a framework that doesn't adequately support them.

--
Andy Lowry, lowry@watson.ibm.com, (914) 784-7925
IBM Research, P.O. Box 704, Yorktown Heights, NY  10598