Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!rice!uw-beaver!apollo!apollo.hp.com!mishkin
From: mishkin@apollo.HP.COM (Nathaniel Mishkin)
Newsgroups: comp.sys.apollo
Subject: Re: The White Paper
Keywords: RPC, networking
Message-ID: <471b93ba.20b6d@apollo.HP.COM>
Date: 28 Nov 89 14:52:00 GMT
References: <14983@joshua.athertn.Atherton.COM> <31904@cci632.UUCP> <46f42a6a.20b6d@apollo.HP.COM>
Sender: root@apollo.HP.COM
Reply-To: mishkin@apollo.HP.COM (Nathaniel Mishkin)
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 130

In article <14983@joshua.athertn.Atherton.COM>,
joshua@athertn.Atherton.COM (Flame Bait) writes:
> Had you actually written any Sun RPC programs at the time you wrote
the paper?
> I got the impression that the author of the White Paper had not actually used
> Sun RPCs. 

I've (a) read all the available documentation, (b) looked closely at
several programs (including Sun's samples), (c) tried to write some simple
programs, and (d) read the Sun RPC source code.  Based on all of that,
plus my native intelligence, I think I'm competent to comment.

> >Second, I take personal responsibility for
> >the content.  This is NOT some official pronouncement of HP.  
> 
> Too late for that.  The copy I got about 10 months ago from Apollo has 
> Apollo's name all over it, and does not have your name on it at all.
> It was an "official pronouncement" of Apollo then :-).

I'm afraid I don't have 100% control over what the marketing folks do.
I accept your criticism though.

> 0. The paper is out of date by two years at least.  Many things have chagned
>    since it was written.

Well, first of all, as you've said, *you're* comments might be out of date.
In fact they are, since the paper I just distributed is different from the 1/88
version.  Given the way the world works, it's just not possible to (a) always
update these things as frequently as everyone would like, and (b) purge all
existing old copies of documents to make sure no one gets the wrong impression.
This is why I put dates on the paper (at least I started doing that some time
ago).  Give me a break.

> 1. The paper is marketing propaganda with a thin veneer of technical
knowledge.

Remarkable.  I wrote the paper.  I consider myself to be solely technically
oriented.  I believe I have a pretty good understanding of all the technical
issues.

> 2. Never use the paper's arguments in a debate with someone who understands
>    Sun's RPC: you'll be cut to shreads.  The facts about Sun's RPC are often
>    out of date or inaccurate, the facts about Apollo's RPC are often 
>    technically acurate, but totally misleading.

Let's have a list of the parts that are out of date or inaccurate.  

Based on my best recollections of the various versions of the paper and
of Sun RPC, the areas of old versions of the paper that might be out
of date relate to RPCGEN.  I think at the time of the first version of
the paper, there wasn't an RPCGEN at all.  Later there was an RPCGEN,
but it generated only server stubs, not client stubs.  Last I looked,
RPCGEN did both stubs, but still allowed only for procedures that take
one input parameter and return outputs as function values.  Recently,
Sun/Novell/Netwise made an announcement that said that the Netwise RPC
TOOL stub generator would generate stubs that talk to the Sun RPC runtime.
As far as I know, this is not available to the general public, if it's
even available at all.  (Note that the Netwise interface language is
significantly different from Sun's [RPCL].  So much for compatibility.)

>     If you make a feature by feature comparison, Apollo's networking system
>     has more features than Sun's.  

Glad to hear we agree on at least one thing :-)

>     But, if you want simplicity and ease of
>     use, then Sun's is the winner.

Of course I disagree.  I'll happily let the world decide whether in fact
for a broad class of applications Sun RPC is either simpler or easier
to use.  I don't think it's simpler to have to understand when to use
UDP and when to use TCP.  I don't think it's simpler to have to know
whether my input or output parameters are larger than 8K.  I don't think
it's easier to use when I can only pass one parameter as input thereby
requiring me to manually write code to assign my "logical" input parameters
into fields of a struct before making a remote call.  I don't think it's
easier to use when I have to remember when I do and when I don't have
to explicitly free storage that the stubs have malloc'd for me under
the covers.

>     For example, Apollo's RPC forces you to use their beefed up UDP transport
>     protocol.  Sun's RPC allows you to use UDP or TCP as a transport
protocols,
>     your choise.  

See above.

>     Apollo makes it very difficult to use any interface
>     language except NIDL.  Sun provides RPCGEN, but also makes it easy to
>     roll your own interface language, if you want to.  Apollo makes it very 
>     difficult to use any data representation except their's (NDR).  Sun makes
>     it easy to replace their representation (XDR), if you want to.

Sure.  And I don't like C, but since the 68000 instruction set is public,
I can write a compiler for my own language.  What's the point?  Most
people don't want to write compilers; they want to get their jobs done.
They want to be supplied with a competent set of tools; they don't want
to reinvent the world.

In any case, both Sun RPC and NCS have runtime libraries that export
routines used by the stubs.  I don't see that either system has any
particular advantage in making any happier the small percentage of people
who want to design their own interface definition language and implement
a compiler for it.

>     The know this is an emotional issue, but lets face it.  Sun's RPC source
>     code has been freely distributable for three or four years.  Apollo's
>     source is still not freely distributable.  Apollo uses a proprietary,
>     private communications protocol.  Sun uses public protocols when
possible,
>     and publishes their protocols, when they are forced to create their own.

Both Sun RPC and NCS run (can run) on top of UDP/IP.  However, they're
both "private communication protocols".  The Sun RPC spec doesn't just
say "use UDP/IP".  It says "use UDP/IP in the following way".  That's
a protocol.  NCS does the same thing.  Admittedly, the NCS protocol is
more complicated, but that's because it does more things.  In any case,
the specification for both protocols are public and published.  (The
book "Network Computing Architecture" just published by Prentice-Hall
contains the complete specifications of the NCS RPC protocols.)

As far as availability of source code, sure, Sun gives theirs away and
we charge for ours.  I'll let the market decide whether what we have to
offer is worth the price.  (Also, I'll be interested to see whether Sun
gives away the source the the Netwise RPC TOOL compiler, which they claim
is the future of Sun RPC.)

                    -- Nat Mishkin
                       Hewlett Packard Company / Apollo Systems Division
                       mishkin@apollo.com