Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!uw-beaver!apollo!mishkin
From: mishkin@apollo.uucp (Nathaniel Mishkin)
Newsgroups: comp.sys.apollo
Subject: Re: NCS vs NFS+rpc (In Japanese/Kanji)
Message-ID: <3b66e520.13422@apollo.uucp>
Date: 11 Apr 88 18:08:00 GMT
References: <7075@etlcom.etl.JUNET> <3b57a3de.13422@apollo.uucp> <1848@ssc-vax.UUCP>
Reply-To: mishkin@apollo.UUCP (Nathaniel Mishkin)
Organization: Apollo Computer, Chelmsford, MA
Lines: 57

In article <1848@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes:
>> In article <7075@etlcom.etl.JUNET> kato%etl.jp@relay.cs.net writes:
>> >[2] NCS vs NFS+rpc
>Actually this may be of interest to you and others but an article I 
>finished reading recently (I am sorry...don't know what mag) mentioned that
>AT&T was adopting Sun's ONC (Open Network Computing) and not Apollo's
>NCS.  (I will try to dig up the article and give you the reference)
>ONC has been around a bit longer than NCS and is based on RPC (Remote
>Procedure Call) specification.  The ONC platform also includes
>exdended data representation (xdr). XDR provides an vendor-independent
>method of representing data. There are a number of elements to ONC
>(like NFS, REX (Remote Execution service)....

Just in case it's not clear, NCS supports a data representation protocol
as well (NDR, Network Data Representation), which we feel has certain
advantages over XDR.  In particular, with NDR, if the communicating
machines have a common data representation (that is one of a set of popular
data representations), no data conversion is done when those machines
talk to each other.  With XDR, supposing you have two 368-based Unix
systems talking to each other, integers are swapped twice -- once by
the sender and once by the receiver -- when those systems talk to each
other.  If you think that the byte-swapping is in the noise (it's not
clear it is as network throughput gets better) consider two processes
talking to each other on the same 386-based machine via RPC.  In this
case, the communications overhead is small and the byte-swapping would
seem to be a bottleneck.  Further, in the case of floating point numbers,
*any* conversion -- no matter how efficient -- might be considered
numerically unacceptable.

>Sun's ONC architecture has been around for awhile and has a number
>of adopting vendors...(Alliant,Apollo, Arete, DEC, Dana, Gould, Harris,
>HP, Honeywell, Masscomp, MIPS, NEC, Pyramid, Ridge, SGI, Sony, Stellar,
>etc) and universities.

Excuse me if I claim that this list is a bit of hype.  For example, Sun
declared that Apollo has "adopted ONC" based on the fact that we support
Sun NFS.  That's a fairly outlandish extrapolation, from our point of
view.  No one asked us if we thought we had "adopted ONC".  Thus, it's
hard to know what to make of the other people on that list.  In any case,
I doubt that the number of sophisticated applications built on top of
anyone's RPC system is very large, and in particular, I wouldn't be
surprised if there are a comparable number of remote procedure definitions
written in NCS and in ONC.  (I'll admit that Apollo may be the source
of many of the NCS definitions, but Sun is probably the author of most
of the ONC definitions as well.)  (Major bias alert:  Further, I can't
imagine writing sophisticated applications like our replicated location
database service, user registry, or license server using the limited
tools that ONC provides.) So the issue of how many people "adopted ONC"
or how long ONC has been around doesn't seem very important.  Certainly,
it's still early enough to make judgements based on technical merit.


-- 
                    -- Nat Mishkin
                       Apollo Computer Inc.
                       Chelmsford, MA
                       {decvax,mit-eddie,umix}!apollo!mishkin