Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!ames!uhccux!waikato!comp.vuw.ac.nz!cc-server4.massey.ac.nz!G.Eustace
From: G.Eustace@massey.ac.nz (Glen Eustace)
Newsgroups: comp.unix.questions
Subject: Writing RPC Server code
Message-ID: <1990Nov18.215509.26571@massey.ac.nz>
Date: 18 Nov 90 21:55:09 GMT
Organization: Massey University, Palmerston North, New Zealand
Lines: 50
X-Reader: NETNEWS/PC Version 2.1

I am just starting to write some programs that use RPCs but have hit
a problem.  I admit to being a complete novice in this area.  I have
RTFMs but still am not sure where I am going wrong.  It could well be
that I simple don't understand what I am reading.  I would be very
appreciative of someone pointing me at the error in my ways or
sending a fragment of code that achieves the correct result.

All the examples of RPC servers that I have seen seem to rely on the
client calls being able to be executed rapidly.  Hence all client
calls can and are serviced by a single daemon e.g. mountd, quotad etc
etc.

What I was hoping to do was the following;

Client side.
============

clntudp_create();
...
clnt_call();   /* rpc procedure 1 */
...
clnt_call();   /* rpc procedure 2 */
...
clnt_call();   /* rpc procedure 3 */
...
clnt_destroy();

some of the rpc procedures may take a non-trivial length of time.

What I thought was the correct thing to do, on the server side, was
to create a new instance of the daemon when the clntudp_create is
executed and let that client/server pair talk to each other until the
clnt_destroy at which time the server terminates.  My thinking was
that additional client/server pairs would be created as needed.

I can't seem to work out how one can actually do the above.  By
implication I am wondering if this is the correct way to do things.
If it is, how does one handle the new client/server pairs in the
server code?  If it is not the correct way to do things how does one
prevent a new client from having to wait for an earlier one to
complete its processing?  My line of thought was based on the TCP
idea i.e. telnet, where a connection is made on a well known port and
then the server and client shift their conversation to another thus
making the well known port available for a new connection.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Glen Eustace, Software Manager, Computer Centre, Massey University,
Palmerston North, New Zealand.        EMail: G.Eustace@massey.ac.nz
Phone: +64 63 69099 x7440, Fax: +64 63 505 607,    Timezone: GMT-12