Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!unmvax!pprg.unm.edu!topgun.dspo.gov!lanl!cmcl2!adm!xadmx!Kemp@DOCKMASTER.NCSC.MIL
From: Kemp@DOCKMASTER.NCSC.MIL
Newsgroups: comp.unix.wizards
Subject: Re: How to use Sun RPC for large slow procedure calls
Message-ID: <21072@adm.BRL.MIL>
Date: 6 Oct 89 14:35:54 GMT
Sender: news@adm.BRL.MIL
Lines: 37

Gregory Bond writes:
 > [description of RPC based database application that sometimes
 >  takes a long time for lookups]
 >
 > Does anyone have any idea how to approach this sort of RPC
 > application?  [...] Or do I drop Sun RPC entirely as the wrong
 > tool and handcraft something using "raw" TCP sockets?

No need to use sockets.  However you are correct in stating that
lengthening the RPC timeouts is a bad idea.

The accepted solution to this very common situation is to use callback
RPC's, in a scenario something like this:

 1. Client requests an action
 2. Server does whatever can be guaranteed to finish quickly (checking
    request validity, user authentication, whatever) and acknowledges
    the request
 3. Server does the lengthy job (computation or database lookup) and
    when it's finished, sends a callback RPC to the client

This is analagous to asynchronous I/O, and requires a similar amount of
care by the programmer to do the job right.  Nonetheless, it *is* the
right way to do it.  I am constantly annoyed by people who write Sunview
programs that do lots of computation in notifier event routines, instead
of just starting a job and returning.  What you are left with is a
window that just sits there for seconds or minutes, refusing to refresh
itself.

If you want to get fancy, you could have a 'progress meter' that gives
the user some feedback as to how his database query is progressing (and
lets him know if the database server or the net goes down), and gives
him some opportunity to abort the job if it is taking too long or not
going in the right direction.


   Dave Kemp <Kemp@dockmaster.ncsc.mil>