HDTenEightyP/NetNews huggingface dataset:
From: durai@ortta.umn.edu (Durai Venkatasubramanian)
Subject: c/s information resource
Organization: U of Mn
Date: Mon, 11 Jan 1993 23:32:20 GMT

I had posted a request seeking info on faq, books on c/s.  I recd replies 
ranging from "go read magazines" to a few specific pointers.  Thanks for all 
those kind souls who bothered to reply.  The following is the summary, for 
other netters consumption.

1. A guide to developing Client/Server SQL applications
   Setrag Khoshafian et al
   Morgan Kaufman Publishers, $ 32.95
   ISBN 1-55860-147-3
   Ph: (415)578-9911

2. Microsoft SQL Server Resource Kit
   Microsoft

3. Client/Server Programming with OS/2 2.0 (2nd
   Edition) by Robert Orfall and Dan Harkey.  It is OS/2centric, but
   nevertheless gives a very good overview of client/server computing in
   an open environment which might include SNA mainframes, UNIX servers,
   and of course OS/2 client and server machines.  They even mention The
   Emporer's New Technology. :-)

   The book is published by Van Nostrand Reinhold and is over 1000 pages.
   ISBN 0-442-01219-5.
From: wagner@cs.unc.edu (Michael Wagner)
Newsgroups: comp.client-server
Subject: How to use svc_getcaller((SVCXPRT *) cl)
Date: 12 Jan 1993 13:04:13 -0500
Organization: The University of North Carolina at Chapel Hill
Distribution: world
NNTP-Posting-Host: paganini.cs.unc.edu


I am developing an application that is using SUN RPC.
The server may be contacted by many different clients,
and needs to know who they are.  My man page says that
svc_getcaller() is the way to do this:

     struct sockaddr_in * svc_getcaller(xprt)
     SVCXPRT *xprt;

          The approved way of getting the network address of  the
          caller  of  a procedure associated with the RPC service
          transport handle, xprt.


I tried to use svc_getcaller() as follows (for non-C++ programmers,
think of cout << as a print()).  This *doesn't* work.  I always get
the same family, port, and addrs printed out, even when I have
two clients on different machines.  They all look like nonsense
values.  Am I doing something wrong?  Has anyone else gotten
this to work?

/******************************************************************/
struct sockaddr_in old_caller;

	/* .
	   .
	   . */
int
check_caller(CLIENT * cl)
{
        struct sockaddr_in *caller = svc_getcaller((SVCXPRT *) cl);
        cout << "caller: family: " << (unsigned short) caller->sin_family
        							<< "\n";
        cout << "caller: port:   " << caller->sin_port << "\n";
        cout << "caller: addr:   " << (char *) inet_ntoa(caller->sin_addr)
        							<< "\n";
        if ((caller->sin_family == old_caller.sin_family) &&
            (caller->sin_port == old_caller.sin_port) &&
            (caller->sin_addr.s_addr == old_caller.sin_addr.s_addr)) {
                 cout << "callers are the same\n";
                return (1);
        } else {
                cout << "callers are different\n";
                old_caller = *caller;
        }
        return (0);
};
/******************************************************************/

Thanks for any help.

Mike Wagner
wagner@cs.unc.edu



-- 
.......................................................
michael paul wagner
wagner@hatteras.cs.unc.edu		ahlan wa sahlan
.......................................................
From: saw@cs.purdue.edu (Sanjiva Weerawarana)
Newsgroups: comp.client-server
Subject: Re: RPC Programming and Client-Server References
Followup-To: poster
Date: 12 Jan 1993 11:15:40 -0500
Organization: Department of Computer Science, Purdue University
NNTP-Posting-Host: lanka.cs.purdue.edu

Since I didn't see a reference to these...

Doug Comer and David Stevens, "Internetworking with TCP/IP Vol III, 
Client-Server Programming and Applications. BSD Socket Version"
ISBN 0-13-474222-2

Doug Comer and David Stevens, "Internetworking with TCP/IP Vol III, 
Client-Server Programming and Applications. TLI Version"
To appear, 1993.

Both are available from Prentice Hall, College Marketing Department, 
Englewood Cliffs, NJ 07632. Tel: +1 201 767 5937.

I have read parts of the first book (while it was being written) and its
good. Judging from Doug Comer's other books and his style, these ought to
be well worth the money. 

Sanjiva.
--------------------------------------------------------------------------------
 Sanjiva Weerawarana                                          saw@cs.purdue.edu
 Department of Computer Sciences,                                (317) 494-9992
 Purdue University,
 West Lafayette, IN 47907.
Newsgroups: comp.client-server
From: durai@ortta.umn.edu (Durai Venkatasubramanian)
Subject: Novice to c/s
Organization: U of Mn
Date: Thu, 7 Jan 1993 17:52:24 GMT

1. Is there a faq for this forum ?
2. Can someone recommend good books that will help me understand what client/
   server computing is all about ?  
Thanks a ton.
Newsgroups: comp.client-server
From: durai@ortta.umn.edu (Durai Venkatasubramanian)
Subject: Novice to c/s: Setrag Khoshafian's book
Organization: U of Mn
Date: Fri, 8 Jan 1993 19:48:09 GMT

In article <C0JpvE.9J3@dcs.ed.ac.uk> ab@dcs.ed.ac.uk (Albert Burger) writes:
>From: ab@dcs.ed.ac.uk (Albert Burger)
>Subject: Re: Novice to c/s
>Date: 8 Jan 93 17:28:26 GMT
>In article <durai.115.726429144@ortta.umn.edu> durai@ortta.umn.edu (Durai Venkatasubramanian) writes:
>>2. Can someone recommend good books that will help me understand what client/
>>   server computing is all about ?  
>
>The following reference may be of interest:
>
>Setrag Koshafian, et. al.
>A Guide to Developing Client/Server SQL Applications
>Morgan Kaufmann, 1992
>
>I haven't read the book and can therefore not comment on it.
>
Thanks for the info.

I read the book.  It has one chapter on client/server fundamentals, that 
does not cover much.  The book focuses on c/s implementation using sql, and 
covers a few vendors (rdb, ms-sql, oracle, and ibm os/2).  It does not cover 
issues on c/s implementation, from the architecture, implementation, and 
training sides.
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.client-server
Subject: Re: NFS and RPC
Keywords: NFS,RPC
Date: 7 Jan 93 05:40:48 GMT
Organization: Auspex Systems, Santa Clara

>NFS is "stateless",

True (modulo debate about the meaning of "stateless").

>which means that each "write" from the client side
>will result in an open/write/close on the server.  The opens/closes slow
>it down quite a bit over the file-transfers you were comparing it to.

False, at least in the UNIX NFS servers I've seen.  In those, there
aren't any "open"s or "close"s done by the NFS server.  Instead, the NFS
server takes the file handle it was given by the client, asks the
underlying file system to cough up a vnode (or moral equivalent, in
systems that decided to be perversely different) for the file with that
file handle, asks the underlying file system to perform the write (or
whatever) on the file referred to by the vnode, releases the vnode if it
was held, and returns the result.

The "get a vnode" and "release the vnode" operations may be what you're
thinking of as the "open" and "close" operations, but they are *NOT*
what's slowing the writes down; they're relatively cheap, especially if
the file system's data for the vnode in question (inode, or whatever) is
cached.

The writes are slowed down by being done synchronously; see the summary
of responses to the original question for a more detailed discussion.
Newsgroups: comp.client-server
From: dennis@zonzorp.Canada.Sun.COM (Dennis Simpson Sun Canada)
Subject: Re: NFS slowness
Reply-To: dennis@zonzorp.Canada.Sun.COM
Organization: Sun Microsystems, Inc.
Date: Mon, 11 Jan 1993 23:33:16 GMT

Maybe someone can save me digging up the answer.
When we are talking about "losing data" on the nfs server when using
the "evil asynch hack", are we talking about invisible loss? Or are we
talking about "fsck removed this corrupt file during reboot"?

I suspect the former (invisible), and if this is true, how can anyone
make the comment "we have had no problems using this hack"? Unless they
truly believe the gods are watching over them.

Just curious,
dennis

---
/---------------------------------------------------------------------\
|  Dennis Simpson      dennis@canada.sun.com <at work>                |
|                      daddy!dennis@zonzorp.canada.sun.com <at home>  |
|  "I like the customer, in theory..."  - G. Rosser                   |
\---------------------------------------------------------------------/

Newsgroups: comp.client-server
From: gjm@dasc.nl (Gijs J. Mos)
Subject: Re: NFS and RPC
Keywords: NFS,RPC
Organization: Data Sciences B.V.
Date: Thu, 7 Jan 1993 10:41:50 GMT

guy@Auspex.COM (Guy Harris) writes:

>>NFS is "stateless",

>True (modulo debate about the meaning of "stateless").

>>which means that each "write" from the client side
>>will result in an open/write/close on the server.  The opens/closes slow
>>it down quite a bit over the file-transfers you were comparing it to.

>False, at least in the UNIX NFS servers I've seen.  In those, there
>aren't any "open"s or "close"s done by the NFS server.  Instead, the NFS
[stuff describing UNIX implementations deleted]

On Stratus NFS the NFS server regularly opens the file. This is indeed a very
slow operation that involves directory access. To make things usable the
NFS server doesn't close files immediately after each write or read. Instead
the files are kept open for a certain period. The time files are kept open is
an installation parameter for the NFS server.  It is normally 30 seconds
or so. This means that a write/read benchmark that writes/reads a stream
of blocks as fast as it can incurs only one open.

Gijs Mos
gjm@dasc.nl
#include <stddisclaimer.h>       This might not be the view of my employer.
Newsgroups: comp.client-server
From: john@iastate.edu (John Hascall)
Subject: Re: NFS slowness
Organization: Iowa State University, Ames, IA
Date: Mon, 11 Jan 1993 04:56:57 GMT

weltman@adoc.xerox.com summarizes:
}  I received a number of informative responses to my question
}about why large NFS writes are so slow ...

}From auspex.com!guy Thu Dec 31 11:08:24 1992
...
}The Prestoserve board acts as "some form of storage that survives a
}server crash", but can be written to faster than can a disk ...

}"Niche" in the hardware sense, or the marketplace sense?  They offer
}both VMEbus and SBus versions for Suns; I don't know if their DEC
}version is a Turbochannel board or not.

As I understand it (we don't have any, we use the evil asynch hack*),
it sits in one of the memory board slots.

* I guess you could say Liebert makes ours ;-)

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systmes Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551
From: wagner@cs.unc.edu (Michael Wagner)
Newsgroups: comp.client-server
Subject: Re: RPC Programming ...
Date: 12 Jan 1993 13:16:04 -0500
Organization: The University of North Carolina at Chapel Hill
NNTP-Posting-Host: paganini.cs.unc.edu

In article <1iupiiINN5a9@ef2007.efhd.ford.com> krishnan@pms240.pms.ford.com (Hare Krishnan) writes:
>
>Could some one let me know of few good references for RPC programming.
>

Try:

	Corbin, John R. "The Art of Distributed Applications",
		Springer-Verlag 1991 (Sun technical reference
		library). 

		ISBN 0-387-97247-1

	Has sveral examples, and a fair amount of explanation.
	The author apparently works at Sun.

Mike Wagner
wagner@cs.unc.edu


-- 
.......................................................
michael paul wagner
wagner@hatteras.cs.unc.edu		ahlan wa sahlan
.......................................................
From: nicklas@access.digex.com (Randolph C Nicklas)
Newsgroups: comp.client-server
Subject: MS-Windows for Critical Apps
Date: 10 Jan 1993 02:50:21 GMT
Organization: Intelsat, Washington, D.C., USA
Distribution: world
NNTP-Posting-Host: access.digex.com

My company is considering using Windows 3.1 (W3.1) for a mission
critical application.  Mission critical in general are applications
such as nuclear reactor systems, air traffic control systems, and
manned space flight systems.  Mission critical in our application
means real-time, multiply concurrent applications consisting of
custom-built W3.1 applications, commercially-off-the-shelf (COTS)
products, ethernet LAN programs with both incoming and outgoing
traffic, older custom-built DOS applications, and X-Windows
displays exported from X-applications on the LAN for monitoring and
controlling a fleet of up to 25 publicly used communications
satellites.  This W3.1 user station is the only access point into
a distributed computing environment of over 40 server machines; if
the user station malfunctions there is no other alternative access
available.  Our design is primarily using W3.1 as a client to
several UNIX servers over the ethernet LAN.

We are searching for people or organizations who currently are, or
are planning to, use W3.1 for mission critical projects to share
with us their key reasons for deciding on W3.1.  We are also
looking for groups that have investigated W3.1 and decided not to
use it for mission critical applications and the reasons why.

We know that many people have strong opinions about W3.1 and we
respect those opinions; however, we are looking for cases that
actually evaluated W3.1 and have made a go/no-go decision for using
it.  Also if there are report/articles/studies on using W3.1 for
mission critical projects -- either pro or con -- we would be
interested in knowing about such.

Thanks in advance for any and all assistance.
-- 
Randolph C. Nicklas                                nicklas@digex.com
Ground Networks Engineering Department             202.944.6938
International Telecommunications Satellite Organization (Intelsat)
From: krishnan@pms240.pms.ford.com (Hare Krishnan)
Newsgroups: comp.client-server
Subject: RPC Programming ...
Date: 12 Jan 1993 15:53:54 GMT
Organization: Ford Motor Company
Distribution: world
NNTP-Posting-Host: pms240.pms.ford.com


Could some one let me know of few good references for RPC programming.

Please send me email to krishnan@pms030.pms.ford.com.

Thanks in advance.
From: ab@dcs.ed.ac.uk (Albert Burger)
Newsgroups: comp.client-server
Subject: Re: Novice to c/s
Date: 8 Jan 93 17:28:26 GMT
Reply-To: ab@dcs.ed.ac.uk (Albert Burger)
Organization: Department of Computer Science, Edinburgh University

In article <durai.115.726429144@ortta.umn.edu> durai@ortta.umn.edu (Durai Venkatasubramanian) writes:
>2. Can someone recommend good books that will help me understand what client/
>   server computing is all about ?  

The following reference may be of interest:

Setrag Koshafian, et. al.
A Guide to Developing Client/Server SQL Applications
Morgan Kaufmann, 1992

I haven't read the book and can therefore not comment on it.

A.
+----------------------------------------------------------------------------+
|   Albert Burger, University of Edinburgh, Department of Computer Science   |
|    JCMB #1410, The King's Bldgs., Mayfield Road, Edinburgh EH9 3JZ, UK     |
|  Phone: +44 (31) 650-5165, Fax: +44 (31) 667-7209, Email: ab@dcs.ed.ac.uk  |
+----------------------------------------------------------------------------+
Newsgroups: comp.client-server
From: steinar@ifi.uio.no (Steinar Kj{rnsr|d)
Subject: Re: NFS slowness
Organization: Dept. of Informatics, University of Oslo, Norway
Date: Tue, 12 Jan 1993 14:47:59 GMT
Originator: steinar@drott.ifi.uio.no


In article <1993Jan11.233316.989@newscan.canada.sun.com>, dennis@zonzorp.Canada.Sun.COM (Dennis Simpson Sun Canada) writes:
> Maybe someone can save me digging up the answer.
> When we are talking about "losing data" on the nfs server when using
> the "evil asynch hack", are we talking about invisible loss? Or are we
> talking about "fsck removed this corrupt file during reboot"?
> 
> I suspect the former (invisible), and if this is true, how can anyone
> make the comment "we have had no problems using this hack"? Unless they
> truly believe the gods are watching over them.
> 
> Just curious,
> dennis
> 
> ---
> /---------------------------------------------------------------------\
> |  Dennis Simpson      dennis@canada.sun.com <at work>                |
> |                      daddy!dennis@zonzorp.canada.sun.com <at home>  |
> |  "I like the customer, in theory..."  - G. Rosser                   |
> \---------------------------------------------------------------------/
> 

I would like to think that the gods are watching me, but I don't think this
is the reason we have encountered no problems so far.

I think you are running *about* the same risk as when you do normal buffered
writes through the buffer-cache locally. Normally, the cache will be flushed
automagically every nth second by the the update process (or any equivalent) 
or by application generated sync() operations. 

If you for some reason experience a severe server crash between two flushes,
you are a candidate for data loss. In a filesystem local to the server, fsck
normally does a good job bringing the filesystem consistent again. So it does
with any server-exported filesystem. However, the important difference now is what 
happens on the remote client side before the remote application detects the
server failure. I imagine there are worst-case situations where both remote
pending unlink() and write() operations are involved, but I really don't know.

I would be happy to be corrected in the above assumptions by anyone more
knowledgable than me in this case. The assumptions are based on a rough
browsing through the source code for nfs_server.c on a SunOS 4.1.3 system.

 | Steinar Kjaernsroed	Dpt. of Informatics	email:steinar@ifi.uio.no
 |			University of Oslo,               or
 |                      NORWAY                        ..!mcsun!ifi!steinar
From: damon@csc.liv.ac.uk (Damon Chaplin)
Newsgroups: comp.client-server
Subject: Using sockets & X Windows
Date: 11 Jan 93 14:39:13 GMT
Organization: Computer Science, Liverpool University

I'm trying to write a client/server application using X windows
& sockets, but I'm finding it a bit confusing. Can anyone give
me a description of how it should all fit together, or point
me to a good reference?

At present my server loops around an accept() call, processing
requests from the clients. The clients create a socket for any messages
from the server, then connect to the server and 'log on' - telling it the
port to send any messages to. After this, the clients connect to the server
for each request, and it is also occasionally
necessary for the server to broadcast certain messages to all clients.

Do I have to worry about deadlocks, or interrupts?
If the clients receive messages from the server, how do they store it?
(If it's in a SIGIO interrupt, can you use malloc() ?)


Any help would be appreciated.

Damon Chaplin
Newsgroups: comp.human-factors
From: asper@sbctri.sbc.com (Alan E. Asper)
Subject: Re: Wanted - Icon Standards
Organization: Southwestern Bell Technology Resources, St.Louis, MO
Date: Fri, 8 Jan 93 22:06:03 GMT

In article <bkillam-050193140411@bkillam-mac.mitre.org> bkillam@ccel.mitre.org (Bill Killam) writes:
>Is anyone aware of any industry, government, or international standards for
>icons for GUIs?  I'm not looking necessarily for application icons, but
>other icon like folders, files, executable programs, disk drives, etc,. as
>well as some more technical ones like drivers and bridges.  Any help would
>be appreciated.  I'll post a summary of the replies.

ANSI X3V1.9 (information systems/Text- and office-based systems/User-system
Interfaces and Symbols) works on icon standards.

Alan
From: prc@uk.co.gec-mrc
Newsgroups: comp.human-factors
Subject: Request for information on human workload
Date: 12 Jan 93 12:03:47 GMT
Reply-To: prc@uk.co.gec-mrc ()
Organization: GEC-Marconi Research Centre, Great Baddow, Essex

I am looking for information on tools, methods and current research
directions (with pointers to published papers, articles and tool
suppliers if possible) in the field of human workload prediction and
assessment. I am also interested in any case studies of tools/methods in
use in real applications.

If you have any information which might be appropriate, I would be
grateful if you could Email it to me (the address is below). I will post
a summary of the information I receive.

Thanks in advance,

Pete C.
--
Pete Chalmers               | Tel: +44 245 73331 x 3243
GEC-Marconi Research Centre | Fax: +44 245 75244
Chelmsford, CM2 8HN      UK | Internet   : prc@gec-mrc.co.uk
Newsgroups: comp.human-factors
Subject: Looking for different style guides such as OSF MOTIF style guide
From: smp@cerc.wvu.wvnet.edu (Shailesh M. Potnis)
Date: Tue, 12 Jan 1993 13:14:13 GMT
Organization: Concurrent Engineering Research Center

		I am trying to compile user interface styles guides such as
the MOTIF style guide. This is to help us decide which style is most suitable
for our application.
	
	All comments and suggestions in this matter are highly appreciated.
	
		Thanks in advance
	
		Shailesh

-- 
Shailesh Potnis, Associate	|Concurrent Engineering Research
Member of Technical Staff	|Center, West Virginia University
From: GQ.AJC@forsythe.stanford.edu (Andy Cargile)
Newsgroups: comp.human-factors
Subject: Re: Selecting evaluation criterias, NEED COMMENTS!
Date: 11 Jan 1993 08:18:39 -0800
Organization: Stanford University
Distribution: usa
NNTP-Posting-Host: morrow.stanford.edu

JF,
Good question. I'm working on something that sounds similar to the
report you reference. We are calling it a Style Guide, which seems
to be pretty common at least among those who are interested at such
things at the CHI conference. I was a bit unclear, though, whether
you are looking for evaluation criteria for judging interfaces after
the fact, or guidelines for developers in the process of designing
them. I can really only comment on the latter, but operhaps this may
be helpful.

I think it's a fine line between over-specifying and
under-specifying. New developers seem to welcome the detail, since
it gets them started and allows them to become more productive more
quickly. At the same time, you don't want to handcuff the creativity
of more experienced developers. In developing ours, I seem to lean
toward specification, but mostly as examples, rather than hard and
fast guidelines. I also tend to quote Bruce Tognazzini (Tog on
Interface) a lot, especially the part about doing something new and
different just for the sake of it.

One example of how I cut some situations refers to the placement and
spacing of radio buttons and check boxes. Our general guideline is
"Use a consistent value as the separation distance between check
boxes and radio buttons within an application". There are similar
ones for margins, etc. I go a bit further, however, but providing
developers with default values (e.g., 4 vertical white pixels
between check boxes) as a default. In other words, consistency of a
value is the guideline, but if you don't have a specific value, or
don't want to come up with one, here's the one we use pretty
commonly as a default.

Why not specify further? Such detail starts getting in the way in
complex windows especially. Then you get developers having to break
at least one guideline since you've specified so much. A bit more
relaxation in this case through example rather than specification
seems to help.

Of course, this is just the way we work and I'm sure there are other
solutions. I would be happy to send you a copy of the work in
progress if you'd like to see more examples. Also, can you tell me
where I might get a copy of Guidelines for Designing
User-System Interface Software, the report you reference? I don't
seem to be able to find it in our library or bookstore.

Thanks and good luck!
Andy Cargile
Data and Technology Resources
Stanford University

PS: I am in the equivalent of an MIS department at Stanford, not the
academic side. These guidelines will be used by administrative
application developers mostly and do not represent the results of
research or classwork.