🚀 go-pugleaf

In article <1992Oct5.131632.27931@geac.com> allen@geac.com (Allen Septon) writes:


<>   I finally started this newsgroup and have yet to see a posting.
<>   I guess everyone is afraid to be the first poster.
<>
<>   Our current customer base is very reluctant to jump into the new
<>   technology of client/server. We plan to use MS-WINDOWS based frontends
<>   and initially GUPTA for a database on the backend.

Obviously you are not SERVING your CLIENTS ;-)

--
Hardy 
-----
Meinhard E. Mayer,  Department of Physics, UC Irvine 
e-mail: hardy@golem.ps.uci.edu (preferred) or MMAYER@UCI.BITNET

From article <1992Oct5.131632.27931@geac.com>, by allen@geac.com (Allen Septon):
> Hi,
> 
> I finally started this newsgroup and have yet to see a posting.
> I guess everyone is afraid to be the first poster.
> 
> Our current customer base is very reluctant to jump into the new
> technology of client/server. We plan to use MS-WINDOWS based frontends
> and initially GUPTA for a database on the backend.
> 
> What experience have people had with reluctant customers and how have
> you handled it.
>
My opinion:  Client/server architectures fit well with the current
mainframe/terminal based applications in place in many IS shops.
It allows one to continue to use the mainframe as a central data
source, possibly by front-ending it with translation tools or 
a second, more modern, database server.  With the widespread use
of Windows and the Mac, client applications have an existing platform
already in place.

Using existing infrastructure is BONUS in todays climate of tight
budgets.  Client/server also affords a phased approach where 
mainframe systems can be phased out over 5-10 year time spans as
intermediate database servers become more functionally complete.

Would I recommend client/server to a customer who has no
existing infrastucture?  Maybe.  Peer-to-peer may be more
flexible but less supported.  

If you educate your customers, I don't see why they would be
reluctant or scared beyond the nervousness associate with
any type of change.

-- 
........................................................................
Steve Anastasi	        "Give a man a fish, and you can feed him for
smanastasi@mmm.com       a day.  Teach him to fish and you can tax him!"
St. Paul, Minnesota                 - hey, I wrote it!

In article <1992Oct5.131632.27931@geac.com> allen@geac.com (Allen Septon) writes:
   Our current customer base is very reluctant to jump into the new
   technology of client/server. We plan to use MS-WINDOWS based frontends
   and initially GUPTA for a database on the backend.

Client/server is new technology?  It's only been around in the
workstation world for 5-10 years.  I believe the workstation world now
is moving more to peer-peer computing in a truly distributed manner.
Client/server has difficulty scaling to large numbers of systems and
is most appropriate for systems in which the server is much more
powerful than the client.

--
David Forslund
Advanced Computing Laboratory
MS B287
Los Alamos National Laboratory
Los Alamos, NM 87545

Voice:(505) 665-1907
FAX: (505) 665-4939
EMAIL: dwf@lanl.gov

In article <1992Oct5.131632.27931@geac.com>, allen@geac.com (Allen Septon) writes:
>Hi,
>
>I finally started this newsgroup and have yet to see a posting.
>I guess everyone is afraid to be the first poster.
>
>Our current customer base is very reluctant to jump into the new
>technology of client/server. We plan to use MS-WINDOWS based frontends
>and initially GUPTA for a database on the backend.
>
>What experience have people had with reluctant customers and how have
>you handled it.
>
>Allen
>allen@geac.com

    What is the purpose of this group?

Client/Server has been around for quite a while, but most is limited to
file level distribution of computing environment.  What is slow to surface
is sharing of other computing resources within the network environment.
There are limited implementations of things like print servers and
information servers (just specialized file servers).  Even slower to
appear are common usage of compute related servers.
--
Marc S. Gibian			email: gibian@talent.ljo.dec.com
Principal Software Engineer	phone: (508) 486-6598
Digital Equipment Corporation	fax:   (508) 486-6648  or (508) 486-6100

In article <DWF.92Oct5092154@hope.acl.lanl.gov>, dwf@acl.lanl.gov (David W. Forslund) writes:
|> workstation world for 5-10 years.  I believe the workstation world now
|> is moving more to peer-peer computing in a truly distributed manner.
|> Client/server has difficulty scaling to large numbers of systems and
|> is most appropriate for systems in which the server is much more
|> powerful than the client.
|> 
|> --
|> David Forslund

If I take a look at OSF's DCE, or Sun's DOE and DOMF, it seems to me
that the world is indeed going to a client-server paradigm, away from
peer-peer. These client-server systems are supposed to scale to many
millions of machines and many millions of users. What do you have in
mind when you say:

	"I believe the workstation world now is moving more to
	peer-peer computing in a truly distributed manner."

I find that very hard to believe.

-Srivas.

In article <1992Oct5.173444.24966@meaddata.com>, srivasm@meaddata.com (M. C. Srivas) writes:
|> In article <DWF.92Oct5092154@hope.acl.lanl.gov>, dwf@acl.lanl.gov (David W. Forslund) writes:

|> millions of machines and many millions of users. What do you have in
|> mind when you say:
|> 
|> 	"I believe the workstation world now is moving more to
|> 	peer-peer computing in a truly distributed manner."
|> 
|> I find that very hard to believe.
|> 
|> -Srivas.
|> 

 Whoa....It all points to the paradigm you are using. If I set out a bunch of PC's,
and mount file systems from a UNIX host, this is C/S. But if I set up a SUN
workstation to point to another workstations' printer, use xntpd to keep my clock in 
sync with someone else, this is peer to peer computing. Now, if my sun is a 
server for those PC's, we have a mixture of both C/S and peer to peer, but in a
distributed manner. 

 Perhaps it should be looked at from the point of locality (or independence
thereof). I no longer need to "login" to another machine to get access to some
of its facilities (like a news server), and I may also provide a service to 
that machine. Peer to peer implies that I do not rely on another system to 
run, and that I may obtain services from many other systems. X-Stations are C/S
from the X-Stations user, but may be peer to peer from an outside service provider,
since each X station looks like a single machine (i.e. I don't know that 
the user on 'foo' is working from the console or an X-Station).

I agree with the sentiment stated above. We are moving to distributed computing
in a peer-to-peer paradigm for the traditional UNIX workstation. As far as souped
up PC's go, they are evolving towards this, but are still stuck in the more
traditional C/S paradigms.

jon

-- 
Jon Alperin
Bell Communications Research

---> Internet: jona@iscp.bellcore.com
---> Voicenet: (908) 699-8674
---> UUNET: uunet!bcr!jona

* All opinions and stupid questions are my own *

In article <1992Oct5.161336.22273@mmm.serc.3m.com> us267384@mmm.serc.3m.com
(Steven M. Anastasi) writes:
>My opinion:  Client/server architectures fit well with the current
>mainframe/terminal based applications in place in many IS shops.
>It allows one to continue to use the mainframe as a central data
>source, possibly by front-ending it with translation tools or 
>a second, more modern, database server.

The C-S model has existed far more than 5-10 years.  Try 20-25 years,
it predated workstations by over a decade.  The problem is: it ain't easy.

My opinion: mainframes (as we know them) are dead meat.
The dinosaur analogy is a good one, but the conserative inertia lingers.
They will still be around (the so-called "soft"ware insures this).
The faster that older architecture tied applications die, the sooner
more portable implementations will come around.  Problems like 32-bit/64-bit
words, character set differences, the turn of the millenia problem, all
conspire against alot of this.

I'm not certain why the first poster used the adjective "scared."
But it can be take in many contexts.  Change will come, slowly with lots of
gotachas.

--eugene miya, NASA Ames Research Center, eugene@orville.nas.nasa.gov
  Associate Editor, Software and Publication Reviews
  Scientific Programming
  {uunet,mailrus,other gateways}!ames!eugene
Ref: Mathematics and Plausible Reasoning, vol. 1, G. Polya

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
-- 
Warner Losh		imp@parcplace.COM	ParcPlace Boulder
I've almost finished my brute force solution to subtlety.

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?

-- 
Jon Alperin
Bell Communications Research

---> Internet: jona@iscp.bellcore.com
---> Voicenet: (908) 699-8674
---> UUNET: uunet!bcr!jona

* All opinions and stupid questions are my own *

In article <1871@sousa.ltn.dec.com>, gibian@talent.ljo.dec.com (Marc S. Gibian) writes:
|> 
|> Client/Server has been around for quite a while, but most is limited to
|> file level distribution of computing environment.  What is slow to surface
|> is sharing of other computing resources within the network environment.
|> There are limited implementations of things like print servers and
|> information servers (just specialized file servers).  Even slower to
|> appear are common usage of compute related servers.

I agree.  It is quite distressing to me that when I talk about using X to run
simultaneous jobs on a dozen CPUs, people stare at me like I have two heads.
I don't even tell them about RPCs and tossing threads out onto the network, I
am afraid they would burn me as a witch.  I think that part of the problem
is that there really is no _good_ language for programming that sort of thing.
Modula-3 looks like a step in the right direction.

-- 
Larry D. Pyeatt                 The views expressed here are not
Internet : pyeatt@texaco.com    those of my employer or of anyone
Voice    : (713) 975-4056       that I know of with the possible
                                exception of myself.

In article <1992Oct5.190119.21270@porthos.cc.bellcore.com>, jona@iscp.bellcore.com (Jon Alperin) writes:
|> In article <1992Oct5.173444.24966@meaddata.com>, srivasm@meaddata.com (M. C. Srivas) writes:
|> |> In article <DWF.92Oct5092154@hope.acl.lanl.gov>, dwf@acl.lanl.gov (David W. Forslund) writes:
|> 
|> |> millions of machines and many millions of users. What do you have in
|> |> mind when you say:
|> |> 
|> |> 	"I believe the workstation world now is moving more to
|> |> 	peer-peer computing in a truly distributed manner."
|> |> 
|> |> I find that very hard to believe.
|> |> 
|> |> -Srivas.
|> |> 
|> 
|>  Whoa....It all points to the paradigm you are using.
|>
|>  [ some examples of distr processing deleted ]

Agree with all what you say above. However, David W. Forslund's post
seemed to imply that somehow peer-peer was more scalable than c/s, and
that c/s was being abandoned for that reason. I simply questioned
why he felt so.

|> 
|> I agree with the sentiment stated above. We are moving to distributed computing
|> in a peer-to-peer paradigm for the traditional UNIX workstation. As far as souped
|> up PC's go, they are evolving towards this, but are still stuck in the more
|> traditional C/S paradigms.
|> 
|> jon

I dont agree w/ that. If I look at all the distr services I get in my
env, eg,
	- ui (x or open-windows),
	- files (nfs or afs),
	- time (rdate or dtp),
	- directory (x.500 or dns),
	- security (kerberos),
	- print (palladium as well as lpr),
	- news,
	- mail,
I find that all of them are based on the c/s paradigm. Some of these
may not use rpc's, but are client-server nevertheless.

I guess peer-to-peer makes sense in the lower layers (<= 4) of the
iso-osi stack, but above that, a c/s paradigm makes life easier for
the programmer and for system management.

There is a (false) tendency to view the c/s paradigm as all requests
going to giant, very powerful, server in the sky, which leads one to
believe that client-server will not scale well. I was refuting that
point.

-Srivas.

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.  What is slow to surface
>is sharing of other computing resources within the network environment.
>There are limited implementations of things like print servers and
>information servers (just specialized file servers).  Even slower to
>appear are common usage of compute related servers.

Huh?  Obviously I've either been blazing the trail to the future for
the past several years or the above is pretty silly.  File Servers
have been around for a long time, as have print servers (ala Novell
and others), and so-called "information servers" (I assume you mean
database servers) are also commonplace - just because Oracle and
Sybase have been duking it out for top honors on Unix, IBM, and DEC
platforms and noone else seems to have come up with an alternative
that is extremely palatable doesn't give credibility to your
statement.  As for client front-ends to database servers, there are so
many that I lost count at 50 and as OCE starts to become more and more
accepted as the standard for enterprise computing, the number of tools
will explode.
If you are refering to database servers when you refer to "information
servers" then you are incorrect in stating that they are specialized
file servers.  In fact, they are not file servers at all, and machines
that are well suited to act as file servers are typically not well
suited to act as database servers by the nature of the beast.
It is true that "compute related servers" have been slow to appear.
However, the complexity of this task and the small need have dictated
that this option will not be widely available for some time.  Consider
the problems:  1) A network must be able to handle the extra
traffic.  2) The servers must use complex parallel-computing
algorithms to complete tasks, which means that the server must be
coded differently.  3)  Often additional memory, disk drives, or
servers will solve the problem at relatively small expense.  4)
Computing power growing quickly and at the same time becoming less
expensive even more quickly.
The fact that there are few commercially available parallel-processing
machines and that all are prohibitively expensive indicate that the
problems with such architectures are difficult when the processors are
in the same machine - much less in different machines sitting perhaps
several hundred feet to several thousand miles away from each other.

Mikey.
Mac Admin "Emeritus"-WSOM CSG - CWRU / 	Engineer-NewMedia Corp. Cleveland, OH
--
Mikey.
Mac Admin "Emeritus"-WSOM CSG - CWRU / 	Engineer-NewMedia Corp. Cleveland, OH
"I looked up the word 'Basketball Player' in the dictionary and you know what
it said?  NOT YOU." - Sydney, White Men Can't Jump

In article <LOWRY.92Oct6101439@rotor.watson.ibm.com>, lowry@watson.ibm.com (Andy Lowry) writes:
|> 
|> 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.
|> 

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?

-- 
Edward So,  Computing Systems, IBM T.J. Watson Research Center
IBM VNET: EDSO at WATSON       Internet: edso@watson.ibm.com

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

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

In article <1992Oct6.124600.7281@texhrc.uucp> pyeatt@Texaco.com (Larry D. Pyeatt) writes:

> I agree.  It is quite distressing to me that when I talk about using X to run
> simultaneous jobs on a dozen CPUs, people stare at me like I have two heads.
> I don't even tell them about RPCs and tossing threads out onto the network, I
> am afraid they would burn me as a witch.  I think that part of the problem
> is that there really is no _good_ language for programming that sort of thing.
> Modula-3 looks like a step in the right direction.

I like Modula-3 a lot, but while there may be great *potential* for
distributed computing in Modula-3, there isn't much available right
now.  For a really nice distributed programming language that's
available right now, check out SR, yet another fine language from The
University of Arizona.  Version 1 has been available for a few years;
version 2 is now available.  You can ftp it for free from
cs.arizona.edu.

(Disclaimer: I'm not unbiased; I've worked on SR myself.)

-mike

Ada 9X will have a "distributed systems annex" which addresses things
like RPCs and building distributed applications.

Ada 83 is a good language to model such applications.  It's easy to
develop a 'non-distributed' application using tasks.  You can debug
the single program (one of the real pains in developing distributed
systems), and then replace task entry calls with calls to RPCs.

				dave

In article <1992Oct5.173444.24966@meaddata.com>, srivasm@meaddata.com (M. C. Srivas) writes:
|> In article <DWF.92Oct5092154@hope.acl.lanl.gov>, dwf@acl.lanl.gov (David W. Forslund) writes:
|> |> workstation world for 5-10 years.  I believe the workstation world now
|> |> is moving more to peer-peer computing in a truly distributed manner.
|> |> Client/server has difficulty scaling to large numbers of systems and
|> |> is most appropriate for systems in which the server is much more
|> |> powerful than the client.
|> |> 
|> |> --
|> |> David Forslund
|> 
|> If I take a look at OSF's DCE, or Sun's DOE and DOMF, it seems to me
|> that the world is indeed going to a client-server paradigm, away from
|> peer-peer. These client-server systems are supposed to scale to many
|> millions of machines and many millions of users. What do you have in
|> mind when you say:
|> 
|> 	"I believe the workstation world now is moving more to
|> 	peer-peer computing in a truly distributed manner."
|> 
|> I find that very hard to believe.
|> 
|> -Srivas.
|> 

The way I perceive the issue of "C/S vs. P2P" in today's distributed
computing paradigm is as following :

When it comes to the *TRANSPORT* level, P2P is the way the _network_ 
architecture should go. P2P is the essence of Distributed Computing in that 
it enables all nodes on the network to be equivalent to simplify network 
protocol, and to be expandable in its intelligence to manage the network 
resources. One evidence that supports this vision is IBM's extending (or shall 
we say _sustaining_ ?) LU6.2/PU2.1 (which is the only animal that has P2P 
behavior in the old SNA zoo) as the corner stone of its APPN, which is the network
fundation of its new SAA.

The C/S model, on the other hand, will still be the major computing paradigm 
on the *APPLICATION* level. For an application designer, C/S is intuitive
and actually models the real world more closely in a lot of cases.

There's nothing wrong with a C/S *application* built on a P2P *network*; 
Actually, that's probably going to be more and more usual a model you'll
see in the next couple of years. 

However, I do maintain that there is NOTHING wrong with a P2P
application built on a P2P network either.

Hope my thought doesn't SCARE too many people.


-- 
***********   Denys Jyh-Hwa Chen      dchen@ctp.com    1-617-374-8271   ***********
NOTHING IN THIS ARTICLE REPRESENTS VIEWPOINT, OPINION, OR WHATSOEVER OF THE 
ORGANIZATION FROM WHICH THIS ARTICLE IS POSTED.

In article <1992Oct5.190119.21270@porthos.cc.bellcore.com>, jona@iscp.bellcore.com (Jon Alperin) writes:
] In article <1992Oct5.173444.24966@meaddata.com>, srivasm@meaddata.com (M. C. Srivas) writes:
] |> In article <DWF.92Oct5092154@hope.acl.lanl.gov>, dwf@acl.lanl.gov (David W. Forslund) writes:
] 
] |> millions of machines and many millions of users. What do you have in
] |> mind when you say:
] |> 
] |> 	"I believe the workstation world now is moving more to
] |> 	peer-peer computing in a truly distributed manner."
] |> 
] |> I find that very hard to believe.
] |> 
] |> -Srivas.
] |> 
] 
]  Whoa....It all points to the paradigm you are using. If I set out a bunch of PC's,
] and mount file systems from a UNIX host, this is C/S. But if I set up a SUN
] workstation to point to another workstations' printer, use xntpd to keep my clock in 
] sync with someone else, this is peer to peer computing. Now, if my sun is a 

Pardon this naive question, but I'm not sure I see the distinction here.
Haven't you described a) a file server, b) a print server, and c) a time
server? Am I incorrectly using the terms Client and Server (not that
anyone's ever done that ;-)).

(Note: we have a bunch of PCs using Unix workstation print queues and
clock synchronization.)

-- 
Marv Fenner           | Mine. All mine.
Unify Corporation     | Sacramento, CA
Voice: (916)928-6266  | FAX: (916)928-640[23]  | Email: mef@unify.Com 

In article <EMERY.92Oct6134626@Dr_No.mitre.org> emery@Dr_No.mitre.org (David Emery) writes:

   Ada 83 is a good language to model such applications.  It's easy to
   develop a 'non-distributed' application using tasks.  You can debug
   the single program (one of the real pains in developing distributed
   systems), and then replace task entry calls with calls to RPCs.

This type of capability is certainly not unique to Ada.  For example,
Sun RPC's rpcgen facility produces server and client stubs in a way
that if you want to test your program without using RPC's, you can
simply link the client and server code together, leaving out the
stubs, and everything will work.

-- 
Jonathan Kamens                                         jik@MIT.Edu
MIT Information Systems/Athena              Moderator, news.answers
    (Send correspondence related to the news.answers newsgroup
        {and ONLY correspondence related to the newsgroup}
                 to news-answers-request@MIT.Edu.)

In article <LOWRY.92Oct6120218@rotor.watson.ibm.com> lowry@watson.ibm.com (Andy Lowry) writes:

   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.

Could you explain more clearly about which "typical software
technology" you're talking about.

I've had experience creating servers for client-server pairs under two
different systems -- Sun RPC and SYBASE's Open Server (DB-Library and
Server-Library) systems.  Both of these systems provide a base which
makes it just about as easy to create the server as create the client
(although using Sun RPC directly is a bit hairy, using something like
rpcgen does indeed make the process about as easy as I've described).
SYBASE's Server-Library system also handles issues such as
multi-threading in the server almost transparently (i.e., the user
code has to worry about locking, semaphores, etc. where necessary, and
on some systems has to worry about occasionally yielding control in
long-running requests, but that's about it).

(Some of the words and phrases in the preceding paragraph are surely
copyrighted by someone.  So sue me.)

-- 
Jonathan Kamens                                         jik@MIT.Edu
MIT Information Systems/Athena              Moderator, news.answers
    (Send correspondence related to the news.answers newsgroup
        {and ONLY correspondence related to the newsgroup}
                 to news-answers-request@MIT.Edu.)

I thought I posted a message here when this group was started, but I guess it did not go through.

We use Gupta's client/server at work and I really like it.  I am really lookign forward to SQLWindows 4.0, a completely object-oriented system.  SqLBase 5.1 is also very near release.  

As for clients unwillingly to change to client/server, emphasis that the LAN environment, coupled with client/server, will probably be the definite trend in the future.  Gupta estimates the client/server market to be around $200 million currently.  Gutpa expects this figure to jump to 1 billion in the next few years.

Another thing, if the client or customer does not want to change to client/server because he likes his slow mainframe, then emphsis gateway software (which Gupta provides) that will link things like DB2 to the LAN world.

                                     


-- 
                        Chris Bluethman

*--->CompuServe: 72347.3306@compuserve.com
*--->Internet: cdblueth@essex.ecn.uoknor.edu

In article <LOWRY.92Oct6120218@rotor.watson.ibm.com>, lowry@watson.ibm.com (Andy Lowry) writes:
 
|>                                ... sentence deleted.  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

I agree. This misleading naming problem is also present in other areas. For 
example, in knowledge representation the terms catagory and instance, when
applied to concepts, appear to label absolutes. However, catagories can also
be instances - of "catagories of catagories". The same problem is carried over
to object oriented terminologies. 

The solution I like best is to make the relationship between the 
entities/objects/things the focus of the terminology, and label the entities 
with respect to the relationship. Hopefully, the label for the entities then 
carries the notion of "In relation to..." instead of "This is a...". For (an 
unimaginative) example, in the client-server case you label the relationship 
with the word reshnica, the "invoker" is called a resh, and the 
"invokee" is called a nica. When one entity is acting as a "user of services" 
in a reshnica relationship it is called a res, and when an entity is acting as 
a "supplier of a service" in a reshnica relationship it is called an nic. The
entity (resh or nica) that is acting as a res is not fixed during the life
of the relationship.

|> 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.

This asymetry is present in the knowledge representation and object oriented
terminologies also. However, advantage is gained from it through the use of
inheritance.

	- Ajeet.

-------------------------------------------------------------------------------
Ajeet Parhar                         internet : a.parhar@trl.oz.au
Telecom Australia Research Labs.     phone,fax: +61 3 253 6167, +61 3 253 6362
Switched Networks Branch             post     : PO Box 249, Clayton VIC
Network Services & Signaling Section            Australia 3168
-------------------------------------------------------------------------------

In article <1992Oct5.131632.27931@geac.com> allen@geac.com (Allen Septon) writes:


>   Our current customer base is very reluctant to jump into the new
>   technology of client/server. We plan to use MS-WINDOWS based frontends
>   and initially GUPTA for a database on the backend.
>
>   What experience have people had with reluctant customers and how have
>   you handled it.

if i werent' a CS type, i'd be scared of it, also.  i think it's a mistake
to expose the general customer to such techno jargon unless they ask for it!
for example, when was the last time NFS was sold as a client-server file
system?

for example, NFS was accepted on the merits of its functionality/capabilities,
not architecture.

*sarcasm on*

i bet this whole issue started when SUN started to claim they were the industry
leader in client-server computing.  it looks great on paper, and probably was
worth millions on wall street.  then, others jumped on the band wagon.

beyond that, the client server model is just one of many implementation details
that helps satisfiy certain functional requrements.

*sarcasm off*

00c
--
00c -- caveh@csl.sri.com
"X is not a letter, it's a sentence."