Path: utzoo!attcan!uunet!van-bc!ubc-cs!uw-beaver!uw-june!ka
From: ka@cs.washington.edu (Kenneth Almquist)
Newsgroups: comp.unix.wizards
Subject: Re: How to use Sun RPC for large slow procedure calls
Summary: Don't
Message-ID: <9419@june.cs.washington.edu>
Date: 8 Oct 89 07:11:24 GMT
References: <21072@adm.BRL.MIL>
Organization: U of Washington, Computer Science, Seattle
Lines: 31

> Gregory Bond writes:
>> [description of RPC based database application that sometimes
>>  takes a long time for lookups]

Kemp@DOCKMASTER.NCSC.MIL replies:
> 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

Accepted by whom?  The technical problems of implementing RPC systems
are basicly solved.  The political problem of keeping SUN from foisting
lousy software on the world is harder to solve, but it may be that
Gregory can manage to get hold of another RPC system.  (Nat Mishkin
mentions one such system.)  Lacking a good RPC system, I would be
inclined to use sockets rather than SUN RPC.  Kemp acknowledges of
the kludge he describes:

> This is [analogous] to asynchronous I/O, and requires a similar amount
> of care by the programmer to do the job right.

Care of course translates into programmer time.  It won't necessarily
take any longer to in effect build your own specialized RPC mechanism
on top of sockets.  And this latter approach won't force you to mangle
your code to mesh with the IPC mechanism.
				Kenneth Almquist