Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!aplcen!haven!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: <21090@adm.BRL.MIL>
Date: 10 Oct 89 14:14:45 GMT
Sender: news@adm.BRL.MIL
Lines: 58

Kenneth Almquist writes:
 > Dave Kemp (me) replies:
 >> The accepted solution is to use callback RPC's [...]
 >
 > 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 analagous 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.

Or at least programmer thought.  I certainly wouldn't characterize
callbacks as a "kludge", any more than device interrupts are a "kludge"
to get around the problems of polled I/O.  Interrupts, and signals, and
callbacks, (the concepts, not necessarily the particular
implementations) are the elegant solution to the problem of maximizing
the productivity of a multi-threaded system.

The database application can be handled synchronously without much
thought:
 1) Issue a query
 2) Wait for the answer (for as long as it takes)
 3) Continue

or it could be handled asynchronously, with a little more thought:
 1) Issue a query
 2) Do something else (like update the progress meter)
 3) Get signalled when the query is finished
 4) Continue (use the results of the query)

The programmer has to decide what to do while waiting for his answer,
regardless of the mechanism used to get it (sockets, Sun RPC, HP/Apollo
RPC, or whatever).  The synchronous method is a no-brainer.
Asynchronous is not a kludge, it's a matter of good careful human
engineering.

I'll take good tools wherever I can get them.  If GNU RPC :-) does the
job better than SUN RPC, I'll use it.  If you find raw sockets easier to
use and document and port and maintain, then by all means use sockets.
What I don't understand is your crack about "the political problem of
keeping Sun from foisting lousy software on the world".  If you don't
like SunOS, then you certainly don't have to pay for it; you can buy DEC
or HP or Data General workstations instead.  Or, as Mr.  Mishkin
suggests, buy HP RPC to run on your Sun.

The original poster was looking for an answer to his particular problem;
i.e.  he has an application running *now* on Suns, and he needs a
solution.  To say that Sun RPC is 'lousy', that the technical problem is
solved, and that you would use sockets (without giving any examples) is
not very constructive.

   Dave Kemp <Kemp@dockmaster.ncsc.mil>