trebor@lkbreth.foretune.co.jp (Robert J Woodhead) (05/23/91)
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@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. |