Possible solution to the RPC deadlock prob I had

[Robert J Woodhead]

A few days ago I posted a question regarding a RPC deadlock problem
I was having.  Briefly, the sitation was that Client A sends a
message to the Server, which then sends it to Client B, C and D;
this could deadlock if Client B tries to send a message at the
same time, as both B and the Server might be waiting for the other
to reply to it's message.

Batching was not a solution as it must be followed by an unbatched
send -- same problem.

I believe I have come up with a solution to this problem -- it
SEEMS to work -- but I'd like to throw it out onto the net and
ask if anyone can shoot it down.

My solution is this:  I noted that the messages to B,C and D didn't
have to be 100% reliable.  The world wasn't going to come to an
end if a message didn't come through.  So what each client did was
create a UDP callback service the Server could talk to.  When each
client says hello to the Server, the server creates a CLIENT * handle
that describes the client's callback service using clnt_create().

It then (this is the important part) uses clnt_control to set both
the CLSET_TIMEOUT and CLSET_RETRY_TIMEOUT fields to zero timeouts.
Then, when the server does a clnt_call() to one of the callback
services, it does so with NULL for the result XDR routine and pointer
***AND*** a zero timeout in the timeout field.

The result is that 1) the clnt_call() always fails with a timeout
but 2) the message gets through to the clients!  One important note
is that you have to use zero timeouts in the clnt_control() and
clnt_call() routines; a zero in clnt_call() alone still gets you a
timeout problem.

Admittedly, this feels like a classic kludge... but it seems to work.

-- 
+--------------------------------------------------------------------------+
| Robert J. Woodhead, Biar Games / AnimEigo, Incs.   trebor at foretune.co.jp |
| "The Force. It surrounds us; It enfolds us; It gets us dates on Saturday |
| Nights." -- Obi Wan Kenobi, Famous Jedi Knight and Party Animal.         |