rpc registration and how to tell of a cnode death ?

[tim marsland]

In article <1720009 at hpbbi4.HP.COM> markl at hpbbi4.HP.COM (#Mark Lufkin) writes:
>> What!!?  Are you suggesting that Greg rewrites `amd' to use NCS??
>
>	I must admit I have no idea what 'amd' is or where it comes
>       from but the idea is not as stupid as you might think

Well, speaking for myself, not knowing anything about a program generally
stops me from posting replies to people's questions about it :-)

>       ... it does
>	not take long to convert a program (it has been done in house ...
>	could have something to do with the fact that we are pushing NCS
>	now though and having SUNrpc based applications does not look
>       good :-)

Applications like NFS you mean?  Or is that going now?  This is one of the
more serious undercurrents which underlies this discussion.

>       Being serious, the exercise is not as stupid as you would
>	like to imply.

Also being serious, I concur that one can often rewrite programs to use
different RPC paradigm's.  However, I'm not exactly sure how useful
gratuitous rewriting is in the context of the original query (summary:
"How do I register amq?").  Note that `amd' is only(!) about 17000+
lines of cunning C that has been ported to at least ten different vendors
Unix variants ;-)

However, the main reason why I was so shocked by the suggestion (and
shocked I was) is not the idea of rewriting per se, but more that `amd' is
itself an NFS server i.e. it has to be based around SunRPC.
Specifically, rewriting `amd' to use a different RPC paradigm would have
meant rewriting the NFS code in the kernel of the local machine and of all
the mount daemons of the file servers it was accessing, *as* *well* *as*
amd itself.  Quite a few man-months ``conversion'' work for poor Greg
methinks :-)

Perhaps now you understand why I tried to imply rewriting was stupid in
this case, and the general ferocity of my flame?

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

and

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

This is more like it Mark -- thanks.  I'd very much like to read these
documents, and your summary of the factors that influenced the decision is
much appreciated.

>> >> Q-2) If your on a cluster server, is there a way you can tell when/how a cnode
>> >> dies (loses contact with the server) ?  This would seem to be so unusual of a 
>> >> request.
>> 
>> >       Diskless nodes don't core dump (unless
>> >       they have local swap) so you will not be able to get more information
>> >       on why the crash occurred.
>> 
>> That's really neat.  Any reason why?
>
>	Easy ... the crash is put into swap, the swap is on the server which
> we have just lost contact with ...

That's not what I meant i.e. the crash might not be *caused* by a network
error.  For example, there might have been a bug in a pseudo-device I was
trying to add to the kernel (say).  Is it still the case that the client
can't core dump when it panics for non-network-related problems?

>	I will admit to being biased in my opinions but then so is
>	everyone else (and the world would be a boring place if we weren't).

Yes, but.. this is a technical forum, not a marketing forum :), so we've
all got to try and keep our opinions under control wherever possible :-)

>	OK, that's enough from me. I will now shut for a while and try
>	not to offend anyone else (seems to be difficult these days).

Hey, no problem Mark -- it's been fun.  Just hope everyone else has
enjoyed it.  I'll shut up now too.

tim marsland,   <tpm at cam.eng.ac.uk>
information engineering division,
cambridge university engineering dept.,