Path: utzoo!utgpu!cunews!bnrgate!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: markl@hpbbi4.HP.COM (#Mark Lufkin)
Newsgroups: comp.sys.sun
Subject: Re: rpc registration and how to tell of a cnode death ?
Keywords: No Digest Subjects in Unmoderated Mode
Message-ID: <3050@brchh104.bnr.ca>
Date: 4 Jun 91 18:40:00 GMT
Sender: news@brchh104.bnr.ca
Organization: Sunspots, Psuedo-Unmoderated
Lines: 102
Approved: sun-spots@rice.edu
X-Original-Date:    Mon, 28 May 1990 18:11:02 GMT

> 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 ... 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 :-) Being serious, the exercise is not as stupid as you would
	like to imply.

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

	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.

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

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

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

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

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

> >> 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 ...
> 
> >       ... As far as the
> >	server is concerned it simply that it can no longer communicate with
> >	the client.
> 
> Quite.  Getting the client to say ``I've died'' is a bit tricky once its
> dead :-) Detecting when it dies is a bit more feasible - you can
> periodically ping the client workstation to check that it's still
> responding.  There are a few ways to do this:

	Actually, diskless DOES use pinging. When it finds that it has not
	any messages from a client it sends a ping package and expects a
	reply. If after a kernel definable number of tries the client still
	has not responded, then it is declared dead.
> 
> 
> tim marsland,   <tpm@cam.eng.ac.uk>
> information engineering division,
> cambridge university engineering dept.,
> ----------

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

tschuess,
Mark Lufkin
Tech Support
HP GmbH