rpc registration and how to tell of a cnode death ?

[news]

In article 1720009 at hpbbi4.HP.COM Mark Lufkin writes:

> In article 8606 at rasp.eng.cam.ac.uk tim marsland writes:
>> Yawn.  Look, I've got nothing against HP/Apollo NCS, and I've heard that
>> it has some technical improvements over SunRPC.  Great - I have some
>> tentative thought of my own about SunRPC failings.  However, I've never
>> heard the particular technical arguments in favour of NCS (despite asking
>> HP in January), and *would* be grateful if someone would post a brief
>> account of the differences, or points me at an HP document.  Enquiring
>> minds want to know.
>> 
>> To be brutal, I get the feeling that your posting is simply OSF posturing.
>> Fine, there are certainly people out there that like this sort of tosh
>> -- but please don't post it out in the guise of a non-answer to some guy's
>> question about a vaguely related problem.  If you want to advertise
>> NCS vs. SunRPC in this forum, *please* tell us why it's better.
>> ``Because OSF says it is'' is not really good enough!

Well, some time has passed since Mark's response to the request; I
wanted to present another point of view.  Disclaimer: I'm an engineer
for Netwise, and my opinions may not be impartial.  In any case, my
opinions do not reflect any official position of Netwise.

> OK, so I asked for that a bit. I promise I don't work for OSF though.
> It was not OSF posturing but I would admit to NCS posturing - it is
> my opinion though that NCS is better.
>
> The reasons why NCS was chosen over the Netwise/SUNrpc offering were:
> There is a fuller description the following documents:
>
> Apollo NCA and SUN ONC: A Comparison (Nathaniel Mishkin)
>
> A Comparison of Commercial RPC Systems (Joshua Levy)
> A response to the above by Nathaniel Mishkin
>
> I do not have any of these electrponically - if I find them I will
> make them available - if anyone else has them, they could do the
> same (the last two were in comp.misc some time back.

At the time, Mishkin was an employee of Apollo. In June of 1989, Tony
Andrews, a Netwise employee, posted "A Review of Current Product
Offerings", which has various benchmarks of current Sun/Apollo/Netwise
offerings (I believe this was to comp.protocols.tcp-ip). This would be
an appropriate document to look at, along with the ones that Mark
mentioned. I will re-post it if desired.

> Just as a summary of why OSF chose NCS over SUNrpc/Netwise offering:

Mark's reference appears to be the "OSF Distributed Computing Equipment
Rationale", dated May 14, 1990, from the Open Software Foundation. OSF is
specifying an entire Distributed Computing environment--Naming, Security,
Threads, as well as RPC.

OSF chose NCS 2.0: "...a joint submission of Digital and Hewlett-Packard."
This is not a shippable product. It is not appropriate to compare an
unavailable NCS 2.0 against Sun's RPCGen. Sun has announced availability of
the Netwise RPC Tool in the Second Half of 1990 ("Distributed Computing Road
Map--An Outlook on the Future of Open Network Computing" Sun Microsystems,
Inc., dated April 30, 1990). A comparison of NCS 2.0 and these new Sun
offerings would be appropriate. Based on Mark's highlights from the OSF
document:

> - minimal programming complexity - NCS adheres more closely to
>  the local procedure model making it easier to use.

I'm not sure what this is a reference to. Both NCS 1.x and the current
Netwise RPC Tool have been generating C code for client and server
stubs. These stubs handle packing and unpacking the data and
networking operations, making an RPC call appear as if it's a local
subroutine call. Both will continue to use stub generation in future
versions.

Besides the joint Netwise/Sun submission to OSF, Sun submitted RPCGen
separately. Perhaps the OSF is talking about the non-transparency of RPCGen.
I would be interested in seeing some clarification of what OSF is talking
about--it's not clear from their Rationale.

> - the RPC protocol is clearly defined and not subject to change by
>  the user (Netwise RPCTool IDL compiler).

The OSF rationale is referring to Netwise's customization feature. Both
the server and client sides of an RPC call are modeled as a state
machines. A user can add hooks to modify what happens in a particular
state or change the state transitions.

There are 2 implications in the OSF document. The first is that
customization of the RPC specification is not valuable. Netwise's
expericnce has been that customization is important to our customers.
The second implication is that customization creates possible
interoperability problems. 

Since this is a technical forum, an appropriate way to explain
Netwise's philosophy is to provide a real example of customization.
I'll apologize in advance for glossing over some of the details, but
hopefully the general point will be clear:

One of our customers wanted to have a multi-tasking server (i.e., a
server that can handle requests from multiple clients simultaneously).
Multi-tasking servers are quite straightforward in a UNIX
environment--Netwise provides "canned" code to provide a multitasking
server for UNIX systems.  Unfortunately, our customer's OS does not
support the concept of copying network file descriptors on a fork()
call. Saying the problem another way, the OS's fork() mechanism does
not permit multiple processes to use the same address for connections.

Netwise created customization so that a client's first RPC call would
instead perform two RPC calls. The first call is to the named server,
which returns the (unnamed) address of a worker to the client. The
second call is from the client to the worker which establishes a
connection for subsequent RPC calls.

>From the point of view of the applications programmer, a single RPC
call has been performed. The customization, which is declared in the
RPC Specification File, provides a means of containment for the custom
functionality of the call. The application *could* have made a
separate RPC call to get the address of the worker, but that doesn't
permit the applications programmer to maintain the abstraction of the
RPC call. If our customer moves his server to a UNIX environment, he
can simply remove the customization, re-compile, and run with no
modification to the application code.

An RPC Toolkit could include some "standard" set of customization
features, but which ones would you include? Customizations could
include modifications to security, naming, auditing, asynchronous RPC
calls, etc. Which do you include with the Toolkit? Netwise felt the
only sane way to proceed was with having the users add whatever they
want -- an "Open Architecture" approach.

Finally, it's not clear what an "RPC protocol" is or what it would
mean to change one.  My feeling is that the RPC Specification File is
specifying the protocol for some set of RPC calls. The customization
is part of that Specification File. Sure, you could create a buggy
customization. In Toolkits where RPC customization wasn't available,
you could have bugs in the application code performing the
customization. Bugs are bugs. Again, the difference is that Netwise
contains the customization in one centralized location, providing a
layer of abstraction for the applications programmer.

This may well wind up being a *religious issue* about RPC technology. 

> - uniform transport behaviour. NCS does not depend on transport
>  characteristics. An example - if UDP is chosen as the underlying
>  protocol limits are imposed on the size and number of arguments
>  as well as the reliebility. NCS allows the choice of a variety of
>  transports without affecting the operation.

The Apollo NCS 1.x uses datagram-oriented transports. Unfortunately,
RPC needs to be built on top of a reliable transport. Apollo built
their own protocol on top of datagram transports to achieve
reliability. In some (all?) systems, these are not implemented in the
kernel.

It's unclear why a home-brew reliable transport would be superior to
using the reliable transport provided by the OS. It could be slightly
faster in some environments, particularly if few packets are lost.
Tuning in more hostile environments would probably be difficult,
particularly since the application may not have access to the
appropriate real-time tools that kernel code does. Finally, there is
the added code space for implemting the reliable transport on top of
the datagram transport.

In the NCS2.0 product, my understanding is that they will use both
connection-oriented and datagram-oriented transports (Mike?).  The
next-generation Netwise tool will be offering datagram transports.  However,
we will be offering the raw datagram functionality to the application--message
delivery will be unreliable and message size will be limited to the size
permitted by the transport. This is what OSF means when they say we don't have
uniform transport behavior.

Why did we make this choice? Basiclly, we feel that a connection-oriented
transport is the way to go. However, if an applications writer is willing to
deal with the reliability and space constraints, then a raw datagram transport
interface can be used.  Assuming appropriate reliability characteristics for
the datagram transport, we will have much lower overhead per packet than
either flavour of NCS2.0. Finally, a datagram transport is necessary to
support broadcast.

NCS2.0 will run on top of either a datagram or a connection-oriented
transport, but you're really getting a connection-oriented service in either
case. Mike: what will NCS2.0 do WRT broadcast? Will it be available with both
types of transport? If broadcast is not available under connection-oriented
transports, won't this constitute non-uniform transport behavior?

If a Netwise user really wanted unlimited data under datagrams, he could add
it with customization :-).

> - allows integration with a threading package, also integrated with
>  authentication s/w (Kerberos). Also allows a 'pipe' capability for
>  bulk transfer of data.

The Netwise tool has customization that would give the analogue to
'pipe'. The callback customization would allow a server to throttle
data coming from the client.

Sun's RPC currently does not have multithread support; they have
announced multithread support in the Second Half of 1991. They will
have Kerberos in the first half of 1991 (see document reference
above).

Netwise's current products support multithreaded applications (with
the restriction that each connection be accessed within a single
thread). What does NCS2.0 do in environments that don't support
multiple threads?