🚀 go-pugleaf

In article <1992Oct6.121213.20420@porthos.cc.bellcore.com> jona@iscp.bellcore.com (Jon Alperin) writes:
 > In article <Bvo9L5.3GI@solbourne.com>, imp@solbourne.com (Warner Losh) writes:
 > |> In article <1871@sousa.ltn.dec.com> gibian@ljohub.enet.dec.com writes:
 > |> >Client/Server has been around for quite a while, but most is limited to
 > |> >file level distribution of computing environment.
 > |> 
 > |> X has been around for several years and uses a client server
 > |> architecture.
 > |> 
 > |> Maybe you forgot about it?  Or you want to foget about it....
 > |> 
 > |> Warner
 > |> -- 
 > 
 >  Yeah,, but try to explain that the X Client runs on the network server,
 > talking to the X server running on a workstation client. 8-}
 > 
 >  Client/Server is at best ill-defined, since it assumes a host/terminal
 > paradigm, where the client is simply performing some (few) tasks that 
 > used to be handled by a host. If I place a printer directly on my
 > ethernet net segment, and I still use terminals connected to a central
 > host but allow the host to send packets directly to a printer, is this 
 > C?S computing?

Woa!  I think we've got two very different ideas of what client-server
means floating around this discussion.  Jon Alperin appears to take
"Client-Server" to mean a way of configuring hardware: you have some
client machines, and you have some server machines, and the client
machines get services from the (you guessed it!) server machines.
It's a definition that will almost certainly become useless very
quickly, because the boundaries are hardly ever that strict.

I think what everybody else is talking about is a much finer-grained
notion which applies to individual applications.  That is, my X window
applications are "clients" to the X "server" process; many of my
applications are "clients" of the NFS "server" daemon running on my...
um... er... "fileserver" down the hall (or perhaps it's my OS that's
the client in this case?  Not that important); likewise, when I run
applications on the fileserver machine, which I frequently do (so
"fileserver is a bit of a misnomer), they end up being "clients" of
the nfs "server" running on my office workstation.  And so on...

When I hear the term "client-server computing" I almost never think of
physical configurations, but rather logical configurations among
running processes.  I think of RPC as the communication paradigm.
When I hear "peer-to-peer" I think of applications that are
communicating and interacting in much more flexible and general ways
than pure client-server.  They may still be using RPC, but the
distinction between caller and callee is fuzzy at best; processes
import services from other processes and also export services to other
processes, and any given pair of processes may actually switch roles
with respect to each other many times (meaning A makes a call on some
service provided by B at one point, and B makes a call on one of A's
services a little later; I'm not talking about any sort of weird
"turn-around" operation that A and B perform).  Then again, they may
not be using RPC, and notions of "caller" and "callee" may break down
altogether.
--
Andy Lowry, lowry@watson.ibm.com, (914) 784-7925
IBM Research, P.O. Box 704, Yorktown Heights, NY  10598