Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!brutus.cs.uiuc.edu!jarthur!bridge2!mips!prls!pyramid!athertn!joshua
From: joshua@athertn.Atherton.COM (Flame Bait)
Newsgroups: comp.sys.apollo
Subject: Re: The White Paper
Keywords: RPC, networking
Message-ID: <15103@joshua.athertn.Atherton.COM>
Date: 6 Dec 89 05:53:31 GMT
References: <31904@cci632.UUCP> <46f42a6a.20b6d@apollo.HP.COM> <14983@joshua.athertn.Atherton.COM> <2197@cs-spool.calgary.UUCP>
Reply-To: joshua@Atherton.COM (Flame Bait)
Organization: Atherton Technology, Sunnyvale, CA
Lines: 102

> = Maurice Sharp from sharp@ksi.cpsc.ucalgary.ca
>> = my eariler posting

Maurice ended with this note, which I think is imporant and often overlooked,
so I'm putting it in front:

> And just as a final note, RPC is NOT a good way of distributed processing
> anyway.  If they were smart, they would offer Message passing, or even
> Linda, or maybee all of them :-)

I look at RPC as a sort of temporary kludge, which should go away in three 
to ten years.  Right now programmers, compilers, designers, and everything
else is set up for sequential execution on one machine.  RPC alows us to 
have sequential execution on several machine, one at a time.  Current 
programmers, designers, testers, compilers, etc. are all very comfortable
with that, but it is a waste of hardware.  As people and programs become
more comfortable with distributed systems, things like Messages and Linda
should replace RPC.

>     Actually, Apollo NCS IS faster than the Suns.  I have the source,
>compiled NCS and NIDL on the Suns, and it WORKED first time.  NO bugs
>(unlike NFS for machine X).  Not only that, it took 3 Sun 4 file
>servers to equal the speed of 6 DN3000's for the Mandel demo.

I'm not comparing hardware or distributed file systems, just RPC protocols.
I didn't now anyone used the file system part of NCS.  I thought even
Apollo used Sun's NFS.  Your last sentence seems to say that Sun's are
twice as fast as Apollos, so I'm sure you did not mean it :-)

I assume that "faster" refers to installation time, not run time speed.
The current Apollo RPC system is 4 TIMES slower than Sun RPC system
for 8K packets, which happens to be the size my application uses.
That is using Sun/TCP (for reliablity as good or better than Apollo).
If I use Sun/UDP, it is 8 times faster than Apollo, but not as
reliable.

Note to Nat: I know that Apollo is coming out with version 1.5 "Real
Soon Now", but it is still in beta test and you can not buy it, so 
I'm still giving out speeds for version 1.1.  

> Nonsense.  The Apollo system is Object Oriented.  I would agree
> with a higher learning curve to master it.  However, it is MUCH more
> flexible and MUCH easier to use.  

I assume you are refering to Apollos distributed file system, not their
RPC system.  If you are refering to their RPC system you are wrong.
Object Oriented means three things: data encapsulation, inheritence,
and polymorphism.  Many OO people seem to think you need all three, but
I think that inheritence and one other qualifies a system as OO.

Apollo RPC has only data encapsulation, not inheritence or polymorphism.
By that definition Sun RPC is "Object Oriented" also.

I refer to this as "buzzword object oriented", you give your routines
object oriented names like (object$_method for example) and a consistent 
naming scheme, (UUIDs for example), and claim your system is "object
oriented".  I like Apollo's routine naming system.  UUIDs (with their
location broker) is one of Apollo's best features, much better
Sun's counter part, but they do make make the system object oriented.

>>Apollo's RPC is like PASCAL; Sun's RPC is like C.
>
>     NIDL lets you do Pascal OR C.  You are confusing the interface
>with the implementation.  

I'm sorry; I must not have been clear. I meant that PASCAL and Apollo's 
RPC were paternalistic ("father knows best"), while C and Sun's RPC were
not ("I'll do what I'm told, even if I do not like it").

I do not want to talk about interface langauge syntax (everyone has their 
own favorite), but I will say one sentence:  I thought that both NIDL's 
PASCAL syntax and its C syntax looked like PASCAL, and were almost identical.
This is personal taste, however, just look at example code from all three
to see which one you like better, RPCGEN, NIDL(C), or NIDL(PASCAL).

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

>     NCS does that because the machines are TRANSPARENT.  Try
>interfacing with an IBM using Sun.  Yech, write your own.  For NCS, if
>it exists on the machine, use NIDL and all is OK :-)

Which IBMs are you talking about?  I use NFS on an IBM RT everyday, and I'm
sure it is available for IBM PCs and mainframes as well.  I think your facts
are wrong or out of date, or maybe you are refering to on specific IBM
machine which is not supported (AS/400?).

Transparency is nice, but look at the price:  It forces Apollo RPC to use
the same transport protocol, even when the machine supports several.  So
on a UNIX machine I must use their protocol, even though my application 
could never run on an IBM mainframe, for example.  But Apollo RPC will not
support more protocols because the IBM mainframe can not.  

(By the way, I'm not convinced that Apollo forces one transport protocol
 for transparency.  I think you could have several transport protocols,
 and still have transparency.  The RPC system would use a default protocol
 if your requested protocol was not available to a given machine. Nat, 
 what's the word on this?)

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