HDTenEightyP/NetNews huggingface dataset:
From: mike@pyrite.SOM.CWRU.Edu (Michael Kerner)
Newsgroups: comp.client-server
Subject: Re: scared customers
Date: 6 Oct 1992 14:55:18 GMT
Organization: WSOM CSG, CWRU, Cleve. OH
Distribution: na
NNTP-Posting-Host: pyrite.som.cwru.edu
X-Post-Machine: pyrite.som.cwru.edu

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
Newsgroups: comp.client-server
From: emery@Dr_No.mitre.org (David Emery)
Subject: Re: scared customers
Organization: The Mitre Corp., Bedford, MA.
	<1871@sousa.ltn.dec.com> <1992Oct6.124600.7281@texhrc.uucp>
Distribution: na
Date: Tue, 6 Oct 1992 18:46:26 GMT

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
From: jona@iscp.bellcore.com (Jon Alperin)
Subject: guidelines on Cell Definition
Organization: Bellcore
Distribution: usa
Date: Mon, 5 Oct 92 16:24:20 GMT

Does anyone out there have any guidelines on cell definition? I am starting
to develop a distributed model for one of my applications, and I am 
running up against questions like "how do you define a cell", "what are
the bounds of a cell", and the like. Most of this stuff will focus on 
the OSF DCE Cell Directory stuff, but I am starting to play with multiple security
and name servers for high availability.

 I have yet to see any articles that tackle the issues of cell definition...any
pointers?

-- 
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 *
Newsgroups: comp.client-server
From: imp@solbourne.com (Warner Losh)
Subject: Re: scared customers
Organization: ParcPlace Boulder
Distribution: na
Date: Tue, 6 Oct 1992 17:47:50 GMT

In article <1992Oct6.121213.20420@porthos.cc.bellcore.com>
jona@iscp.bellcore.com (Jon Alperin) writes: 
> 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-}

You're network FILE server has the files on it.  Your X server has the
graphics on it.  You run clients where the resource you are using
isn't.

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

I strongly disagree.  Client/Server model is based on sharing
distributed resources.  When you don't have that resource, you ask
another machine for that resource.  The paradigm is much more general
than host/terminal.  The clients are typically much smarter than mere
terminals.

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

Yes.  The printer that you added to your network is a print server.
The host is offloading its printing needs to the printer.  The fact
that you have terminals connected to the host is non-issue.  I have a
workstation that I print from.  I have little idea of how the printers
are connected to the network.  I just type "lpr" at the prompt or
choose print from the GUI for the program I'm using and it magically
appears at the right place.

Warner
-- 
Warner Losh		imp@parcplace.COM	ParcPlace Boulder
I've almost finished my brute force solution to subtlety.
Newsgroups: comp.client-server
From: dil.admin@mhs.unc.edu (Dave Laudicina)
Subject: re: scared customers
Organization: UNC Office of Information Technology
Date: Tue, 6 Oct 1992 11:57:49 GMT

In article <1992Oct5.131632.27931@geac.com>  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

I think in a lot of cases the demand for client server is customer 
generated. I have some experience with dealing with a large COBOL
mainframe shop. The beast was so hard to get rolling and had such
limited resource do develop the projects demanded that if the
customer did not generate his own apps he either would not see
an app or when it finally got developed it was obsolete or
subject to major changes generated by changes in business. Thats
one nice feature of client server, the development environments
are easy to program new apps and can be generated by technical
expertise in the customer department on top of that you also get a
graphic interface that also increase productivity of the user. My
experience has shown the reluctance is more on the systems department
side.  
 
department 
Newsgroups: comp.client-server
From: sboyle@mbunix.mitre.org (Boyle)
Subject: Re: Defining Client/Server (was Re: scared customers)
Organization: The MITRE Corporation, Bedford, MA
Distribution: na
Date: Tue, 6 Oct 1992 22:46:41 GMT

In article <1992Oct6.121213.20420@porthos.cc.bellcore.com> jona@iscp.bellcore.com (Jon Alperin) writes:
>
> 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. 


Wellllllll, sort of.  I've had the most success explaining any notion
of client-server (including file servers and X Window) by using the
simplifying definition that the server controls some resource and the
client makes request of the server for the resource.  (I don't believe
this restricts the definition to host/terminal systems.) In fact, the
true test is when it's used to describe an X-capable device running
jobs on a compute server while reading and writing files to file
servers.  I've used the above definition and system description with 
success in a number of Intro. UNIX courses I've taught when I describe some
of what people may see in the real world outside of a single-host system.

The definition also seems to work when I use it to describe the
client-server applications we're currently developing; mostly data query
and update from desktops (Macs & PCs) to SQL RDBMS servers.  Anybody want
to talk about trying to develop, debug, profile, and test applications that
span two distinct platforms/OSs over a communications/connectivity link?
(I sure do! :-)

_______________________________________________________________________________
Steve Boyle                  |     "...Actually, FORTRAN was the language
sboyle@mitre.org             |      of choice for the same reason that
The MITRE Corporation        |      three-legged races are popular."
Burlington Road              |
Bedford, MA. 01730           |             - Ken Thompson
(617) 271-2977               |               1984 Turing Award Lecture
Newsgroups: comp.client-server
From: edso@watson.ibm.com (Edward So)
Subject: Re: scared customers
Date: Tue, 06 Oct 1992 15:09:41 GMT
Reply-To: edso@watson.ibm.com		
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center

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
From: dwf@acl.lanl.gov (David W. Forslund)
Newsgroups: comp.client-server
Subject: Re: scared customers
Date: 5 Oct 92 16:21:54 GMT
Reply-To: David W. Forslund <dwf@acl.lanl.gov>
Distribution: na
Organization: Advanced Computing Lab, LANL, NM

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
Newsgroups: comp.client-server
From: allen@geac.com (Allen Septon)
Subject: scared customers
Date: Mon, 5 Oct 1992 13:16:32 GMT
Distribution: na
Organization: Geac Computer Corporation

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
Newsgroups: comp.client-server
From: dil.admin@mhs.unc.edu (Dave Laudicina)
Subject: Re: scared customers
Organization: UNC Office of Information Technology
Date: Tue, 6 Oct 1992 13:04:50 GMT

In article <1992Oct5.173444.24966@meaddata.com> news@meaddata.com (Usenet Administrator) 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.
>
Also ask any two people what client server and peer to peer means
Newsgroups: comp.client-server
From: us267384@mmm.serc.3m.com (Steven M. Anastasi)
Subject: Re: scared customers
Organization: 3M - St. Paul, MN  55144-1000 US
Distribution: na
Date: Mon, 5 Oct 92 16:13:36 GMT

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!
Newsgroups: comp.client-server
From: IMAGING.CLUB@OFFICE.WANG.COM ("Imaging Club")
Subject: Re: Wang OPEN/image AIX client server imaging starts shipments
Organization: Mail to News Gateway at Wang Labs
Date: 06 Oct 92 13:33:05 EST

Regarding that posting about Wang on comp.graphics which you may have
noticed, we can confirm that we are now in volume shipping of our new
Wang client-server RS/6000-based document imaging.  Please feel free to
send in any questions to our worldwide Imaging Club network, and I'll
broadcast them.

----------------------Michael.Willett@OFFICE.Wang.com-------------------

The Wang Integrated Imaging System (recently ranked as the number one
document imaging system by Computerworld) has been ported to AIX, with
equivalent or better functionality, and named OPEN/image for AIX.
Customer shipments began in September.

While "many vendors have been mimicking WIIS...., Wang has stayed ahead
by adding color and gray-scale support.  Wang is the only major
document imaging vendor to have achieved this," said Rich Barrett, manager
of the client/server component of the product.   The development group
also significantly improved the speed of black and white images.

Full information and demonstrations are now available from any
Wang office or Wang imaging business partner worldwide.

Michael.Willett@OFFICE.Wang.com
Newsgroups: comp.client-server
From: srivasm@meaddata.com (M. C. Srivas)
Subject: Re: scared customers
Organization: Mead Data Central, Dayton OH
Date: Mon, 5 Oct 1992 17:34:44 GMT
Distribution: na

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.
From: sterrett@nosc.mil (Anthony E. Sterrett)
Newsgroups: comp.client-server
Subject: clinet-server benchmarks
Keywords: benchmarks,performance
Date: 6 Oct 92 15:22:45 GMT
Article-I.D.: nosc.1992Oct6.152245.9931
Organization: Naval Ocean Systems Center, San Diego, CA


Hi,
	Would anyone like to share or disscuss techiques for
benchmarking client-server systems?
Thanks in Advance 
Tony Sterrett
sterrett@nosc.mil
Newsgroups: comp.client-server
From: cme@ellisun.sw.stratus.com (Carl Ellison)
Newsgroups: comp.client-server
Subject: Re: clinet-server benchmarks
Keywords: benchmarks,performance
Date: 6 Oct 92 21:08:16 GMT
Organization: Stratus Computer, Software Engineering

In article <1992Oct6.152245.9931@nosc.mil> sterrett@nosc.mil (Anthony E. Sterrett) writes:
>	Would anyone like to share or disscuss techiques for
>benchmarking client-server systems?


There's an old client-server benchmark called ET-1 (transaction processing
benchmark for the banking (ATM) community).  The relevant metric is a set
of throughputs (of transactions) at various average response times.
Alternatively (and true for ET-1) there's a single metric:  throughput of
all transactions which completed in under X seconds.  [late transactions
just don't get counted]

This way both communication time and time queuing for communications get
counted in the benchmark.
From: hardy@golem.ps.uci.edu (Meinhard E. Mayer (Hardy))
Subject: Re: scared customers
In-reply-to: allen@geac.com's message of Mon, 5 Oct 1992 13:16:32 GMT
Newsgroups: comp.client-server
Organization: Department of Physics, UC Irvine, CA 92717-4575, USA
Distribution: na
Date: 5 Oct 92 15:41:01 GMT

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: jona@iscp.bellcore.com (Jon Alperin)
Newsgroups: comp.client-server
Subject: Re: scared customers
Date: 5 Oct 92 19:01:19 GMT
Distribution: na
Organization: Bellcore

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 *