Xref: utzoo comp.protocols.tcp-ip:12475 comp.protocols.nfs:1147
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!brunix!m2jhc!jhc
From: jhc@m2jhc.uucp (James H. Coombs)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.nfs
Subject: Re: Books on RPC programming?
Message-ID: <46559@brunix.UUCP>
Date: 3 Aug 90 19:33:13 GMT
References: <296@uucs1.UUCP> <28186@joshua.athertn.Atherton.COM> <140113@sun.Eng.Sun.COM>
Sender: news@brunix.UUCP
Reply-To: jhc@iris.brown.edu (Jim Coombs
Organization: IRIS - Brown University
Lines: 24

In article <140113@sun.Eng.Sun.COM> corbin@sun.UUCP (John Corbin) writes:
>In article <28186@joshua.athertn.Atherton.COM> joshua@Atherton.COM (Flame Bait) writes:
>
>The book will not be out until November 1990.  The title has been changed
>to "The Art of Writing Distributed Applications using Remote Procedure Calls".
>The ISBN is still the same.  Of course I think that the book is good, but
>that is my biased opinion.

Do you discuss techniques for getting a server to fork() copies of
itself, one per client?  I have been looking through the RPC 4.0
distribution and am beginning to think that the RPC communications
model has been implemented too strictly to permit the reasonable use of
fork().  I can modify the code to implement an optional fork, but then
I find that the server does not shut down when the client shuts down.
I have no trouble implementing these requirements (e.g., keepalives)
when working at the socket level.

If you have a way to do this, I would like to hear about it.  Also, if
you have comments on the RPC communications model, that would be
interesting.  Perhaps you do this already, but it would useful to
include a critique of RPC in your book: what is it good for and what is
it not good for, how should it be improved?

Thanks.  --Jim