Path: utzoo!attcan!uunet!ginosko!aplcen!haven!adm!xadmx!weiser.pa@xerox.com
From: weiser.pa@xerox.com
Newsgroups: comp.unix.wizards
Subject: Re: How to use Sun RPC for large slow procedure calls
Message-ID: <21085@adm.BRL.MIL>
Date: 8 Oct 89 10:38:51 GMT
Sender: news@adm.BRL.MIL
Lines: 28

An alternative approach to callbacks is to keep things under the control of
the client using "status" calls.  For instance, we use this in a document
retrieval application here, like this:

Client initiates action, gets back a session handle and a completion
estimate.  The completion estimate is used by the client for a time to
callback and see how things are going (using that same session handle), and
get another completion estimate.  And so on.  Clients that want progress
reports more frequently call back more often--the completion estimate is
just a hint.

This way RPC clients don't have to also know how to be servers, and/or pass
around procedure call handles through RPC's (which would be the extension
of the usual callback method to RPCs).  Server code is also relatively
simple--it generally pretty easy to keep some kind of status report about
how things are going, and to return completion estimate hints that not only
take into account how long the thing is actually going to take but how busy
your are (and so how often you want to hear from the client).

Completion estimates are a three part field: seconds until done, integer
that increases while there is progress, and percent done.  Clients that
want to give progress feedback to their users use the percent done field to
show work getting completed.

Naturally, clients that can't take a hint can bring the system to its
knees.  But that is a universal.

-mark-