Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mephisto!uflorida!beach.cis.ufl.edu!bb
From: bb@beach.cis.ufl.edu (Brian Bartholomew)
Newsgroups: comp.sys.hp
Subject: Re: rpc registration and how to tell of a cnode death ?
Summary: NCS .vs. SunRPC - Technical Superiority or Noise?
Keywords: NCS SunRPC OSF
Message-ID: <23527@uflorida.cis.ufl.EDU>
Date: 13 Jun 90 07:08:55 GMT
References: <1990Jun12.225105.979@athena.mit.edu>
Sender: news@uflorida.cis.ufl.EDU
Reply-To: bb@beach.cis.ufl.edu (Brian Bartholomew)
Followup-To: comp.sys.hp
Organization: UF CIS Department
Lines: 50


> ---( Netwise's introductory text omitted )---
> ---( Defense of example as appropriate omitted )---
>
> One of our customers wanted to have a multi-tasking server (i.e., a
> server that can handle requests from multiple clients simultaneously).
> Multi-tasking servers are quite straightforward in a UNIX
> environment--Netwise provides "canned" code to provide a multitasking
> server for UNIX systems.  Unfortunately, our customer's OS does not
> support the concept of copying network file descriptors on a fork()
> call. Saying the problem another way, the OS's fork() mechanism does
> not permit multiple processes to use the same address for connections.

Let me see if I have this straight.  We are discussing two competing
networking standards, that are or will be released with versions of U*IX. 
But, instead of being shown an example of how NCS is more appropriate 
for U*IX, I am shown how it fixes a problem with another OS.  If there 
can't be found an example that shows it clearly superior for U*IX, 
then perhaps there isn't a clear technical advantage.

> ---( Program flow description omitted )---
> ---( Architectural overview omitted )---
>
> ...If our customer moves his server to a UNIX environment, he
> can simply remove the customization, re-compile, and run with no
> modification to the application code.

If the customer had used a more capable OS in the first place, there 
would be no reason to supplement its features via a networking package 
add on.  So instead, the U*IX users, the vast majority of users for 
whom this standard is being written for in the first place, are to be 
penalized in wasted kernal memory, dead code, and unused features. 

> ---( Tool-building philosophy omitted )---
> ---( RPC toolkit description omitted )---
> ---( History of Apollo implementation omitted )---
> ---( Discussion of what-is-an-RPC omitted )---
> ---( Discussion of features duplicated with U*IX omitted )---

Is there a forest that I am missing, but for all these trees?

"Any sufficiently advanced technology is indistinguishable from a rigged demo."
-------------------------------------------------------------------------------
Brian Bartholomew       UUCP:       ...gatech!uflorida!beach.cis.ufl.edu!bb
University of Florida   Internet:   bb@beach.cis.ufl.edu
--
"Any sufficiently advanced technology is indistinguishable from a rigged demo."
-------------------------------------------------------------------------------
Brian Bartholomew	UUCP:       ...gatech!uflorida!beach.cis.ufl.edu!bb
University of Florida	Internet:   bb@beach.cis.ufl.edu