Path: utzoo!attcan!uunet!samsung!uakari.primate.wisc.edu!sdd.hp.com!apollo!apollo.hp.com!mishkin
From: mishkin@apollo.HP.COM (Nathaniel Mishkin)
Newsgroups: comp.protocols.misc
Subject: Re: RPC Technologies
Keywords: NCS Threads Preemption Portability
Message-ID: <1990Sep12.093500@apollo.HP.COM>
Date: 12 Sep 90 13:35:00 GMT
References: <1990Sep10.182341.11165@athena.mit.edu> <1990Sep11.120119@apollo.HP.COM> <1990Sep11.223905.13417@athena.mit.edu>
Sender: root@apollo.HP.COM
Reply-To: mishkin@apollo.HP.COM (Nathaniel Mishkin)
Organization: Hewlett-Packard Company - Cooperative Object Computing Operation
Lines: 60

In article <1990Sep11.223905.13417@athena.mit.edu>, pae@athena.mit.edu (Philip Earnhardt) writes:
>Who does say what's permitted and what's not permitted in an NCS port?

A good question that many people have tried to address in the context
of many existing protocols (and programming languages, and ...).  I don't
know that I have a good answer.  The strictest answer is that what's
permitted and required are exactly what some spec says is permitted and
required.  The creation of such a spec that is absolutely complete is
a very tricky matter.  It took a long time and a lot of experience to
get, say, the TCP spec(s) (plus notes to implementors) into a state where
multiple implementors who read the specs actually produce implementations
that interoperate.  Even though most people simply clone existing TCP
implementations these days, one STILL sees the occasional interoperability
problem.  What's more, I'm not aware of any official "conformance test
suite" for TCP, although such a existence suite would seem to be an
extraordinarily useful adjunct to specs.

We believe that in the current NCS spec we have gone a long way toward
making a complete spec, but clearly it's not absolutely complete.
Questions such as you're raising -- "Is an implementation conformant
if it can deal only with calls of short duration" -- is not explicitly
addressed in the spec.  It should be.  I am reluctant to strictly disallow
such implementations, since allowing them does have some value.  Let's
say we'd put it in the "Minimal NCA/RPC" appendix to the spec.

By the way, I don't know that I've ever seen a spec of the Netwise RPC
protocol (i.e., the one that your current, non-SunRPC-based products
use).  Can you make one available?

>What's to keep someone from making a port that doesn't interoperate with
>another NCS port?

In general, the only thing that stops someone from making a
non-interoperating implementation (port or brand new) of some network
protocol is market pressure.  What's to keep someone from making an
implementation of TCP that doesn't interoperate with another TCP
implementation?  (Some protocol definers try to leverage the legal system.
As I recall, Sun doesn't let a vendor use the "NFS" trademark unless
the vendor's implementation passes some verification suite.  Not an
unreasonable idea.)

>Do you think it's important to support users in creating portable NCS
>applications? 

No, and I don't like apple pie either :-)

Of course it's important.  But you seem to treat everything as black
and white.  ALL systems have aspects that limit portability to some extent.
Like I said, if I use Sun RPC over TCP and I need to handle 100's of
clients, my application is not going to be portable to systems that support
only 20 file descriptors per process.  Does that mean the system is
useless?  No.  Does it mean it's less useful than one that requires only
1 file descriptor.  To some degree, yes.  How does this "degree" map
onto the space of real world systems and applications?  Time will tell.

--
                    -- Nat Mishkin
                       Cooperative Object Computing Operation
                       Hewlett-Packard Company
                       mishkin@apollo.hp.com