Xref: utzoo comp.protocols.tcp-ip:12515 comp.protocols.nfs:1157
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: <46837@brunix.UUCP>
Date: 8 Aug 90 20:41:57 GMT
References: <296@uucs1.UUCP> <28186@joshua.athertn.Atherton.COM> <140113@sun.Eng.Sun.COM> <46559@brunix.UUCP> <140323@sun.Eng.Sun.COM>
Sender: news@brunix.UUCP
Reply-To: jhc@m2jhc.UUCP ()
Organization: IRIS - Brown University
Lines: 35

In article <140323@sun.Eng.Sun.COM> corbin@sun.UUCP (John Corbin) writes:

>I don't beleive that the RPC model was implemented too tight to allow
>the reasonable use of fork().  I don't know if you have already thought of
>this, but if you want one server process per client, you could have the
>parent process register via the portmapper.  When it gets a request from
>a client, it could spawn a child process that would bind to a different
>port number than the parent process.  The child would not register itself
>with the portmapper.  The child would attach itself to a port using the
>necessary socket calls and then pass the socket descriptor into the
>svcXXX_create() routine.....

This is interesting.  From my perspective, however, I have not gained
much by using RPC if I have to go do this much work at the socket
level.  In part, my evaluation is due to the fact that I frequently
send lists through the network.  RPC's ability to send and reconstruct
lists is attractive in some ways, but I really need Inheritance C
objects, not C structures.  So I have to traverse the list, build a new
list of objects, and free the memory from the original list.  I don't
really consider this a criticism of RPC, but it does limit its
utility.  It's just much simpler to read data from a socket into local
variables, allocate an object, and then initialize the object with the
data.  If I have to deal with sockets anyway, then I may as well do the
whole thing with sockets.  I say this not to convince anyone of
anything in particular, just to expose a line of reasoning that may be
interesting to others.  Happy to hear what I have forgotten, missed,
etc.

>An alternative to forking is the use of light weight processes or threads.

This too is interesting.  I am using c-tree.  I do have the source
code, but I cannot spend a lot of time making modifications.  The other
major problem with LWP is its (current?) lack of portability.

Thanks for the discussion.  --Jim