Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!lll-winken!decwrl!nsc!pyramid!athertn!joshua
From: joshua@athertn.Atherton.COM (Flame Bait)
Newsgroups: comp.sys.apollo
Subject: Re: The White Paper
Keywords: RPC, networking
Message-ID: <15101@joshua.athertn.Atherton.COM>
Date: 6 Dec 89 04:35:28 GMT
References: <14983@joshua.athertn.Atherton.COM> <31904@cci632.UUCP> <46f42a6a.20b6d@apollo.HP.COM> <471b93ba.20b6d@apollo.HP.COM>
Reply-To: joshua@Atherton.COM (Flame Bait)
Organization: Atherton Technology, Sunnyvale, CA
Lines: 110

% = Achille Petrilli
# = Nat Mishkin
> = Joshua Levy (me)

% I would like to see technical comments, even if they are long, I'm 
% interested and would really love to see them. Please post, I believe there 
% is interest in these sort of things.

The quickest summary is: there isn't that big a difference.  Apollo, Netwise,
and Sun all make good RPC systems which will solve almost all of the 
problems you need solved.  This discussion is about which is "better", 
a hard to define idea when it comes to RPCs.  The RPC systems are different, 
however, which provides lots of stuff to talk about.

Unfortunately, I do not have the time to write a good technical comparison 
of RPC protocols (except speed and reliablity, which I already have written).
I'm sorry.  I know how valuable one would be.

Instead, I'll reply to the technical parts of Nat's posting.

% I found NCS a much more finished product (but I'm no expert :-).
% May be is just matter of doc style or whatever else, I don't know.

I can see how you felt that way, and I do not disagree.  In a sense I 
see Apollo's RPC as one tool, while I see Sun's RPC as several cooperating 
tools.  This gives Apollo the finish you talk about;  Sun's architecture
gives it greater flexiblity.

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

Some of these features include: quit propagation, where if the server
routine fails this is echoed back to the client; no time out operation,
where you do not need to specifiy a maximum server time out; and a
better name service.

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

In a sense, you're correct; whenever you force someone to do things one
way, you save them the hassle of making a choice.   I'd rather have
choices and easy to use defaults, if I do not really care.

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

This is a non-issue, at least in my mind.  Both Sun and Apollo allow you to 
pass as many arguments as you want, they use slightly different syntax, but 
it is no big deal.  We can argue about syntax forever, but why bother.

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

Then you'll be happy to know that both Sun and Apollo will free storage
automatically for you.  (Look at the dealloc action for XDR.  I must admit
that I've never used this feature myself, but it looks like it does 
exactly what you want.

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

Using your compiler analogy: C is simple.  I understand how to write
a compiler for it.  Even though I never will, the fact that I could is 
very important.  It shows that the language is understandable.  The fact
that I could write an XDR compiler shows how easy and straight forward
the language is.  The fact that I can not for NDR shows the problem; that
NDR is compilcated.

# They [RPC users] want to be supplied with a competent set of tools; they 
# don't want to reinvent the world.

This is very true, and why I like Sun RPC.  It is a collection of useful
tools which you can combine to solve many problems.  Apollo's RPC is more
like a single tool, which also solves many problems.  But you can not tailor 
it to your particular problem (by choosing a transport layer, or a data 
encoding, or ...) like you can with Sun.

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

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

Besides source code availability, there is also "plain old" availablity.
Take a company which makes a product for IBM RT, DEC ULTIRX, Suns, Apollos,
and HPs, and wants to expand to VMS and IBM PCs.  Sun RPC is available on
all these platforms; Apollo's RPC is not.  (The ringer is the IBM RT, which
does not yet have Apollo RPC, as far as I can tell.)  The bottom line is
that every new UNIX machine coming out now has Sun RPC as part of its 
standard software bundle.  Most of them have Apollo RPC also, but the 
difference between all and most is important.  

Since everyone must use NFS (like it or not) everyone has Sun's RPC.
If you want to pay $25,000 you can get Apollo's RPC also.

Joshua Levy                          joshua@atherton.com  home:(415)968-3718
                        {decwrl|sun|hpda}!athertn!joshua  work:(408)734-9822