RPC Timeouts

In general, a Volity entity should time out Jabber-RPC calls after a short interval. (30 seconds is reasonable.) This can be implemented in the low-level Jabber communication code, so it applies to every RPC call.

Timeout errors can be handled the same way as stanza errors or RPC faults. Most code that sends an RPC call does not care about the result, anyway.


Original text of this page:

What is the policy on timeouts on Jabber-RPC calls?

A distributed system (fancy word) will usually have some notion that if you send an RPC, and N seconds go by, the system assumes that the other end -- or the network in between -- is hung or dead. You "receive" an error reply back (actually generated on your end, of course).

We have the Jabber server watching over us; we'll get presence notification if some Jabber entity in our game actually suffers process death. But that doesn't cover all cases. I am thinking:

(This last case isn't a Jabber-RPC timeout, and it might seem dumb, but every extant referee is a resource load. We may want code in the parlor to abort a game if there's no activity on it for N hours. (Some server-configured interval.) (See table timeouts for this issue.)

I am willing to let the game author ignore these issues. The referee has a limited lifespan, and if there are some unresolved RPCs hanging around when the game ends, no biggie. (Although our low-level volity classes should be smart enough to free that memory.)

The parlor, however, should have some policy about hung RPCs, hung games, etc.

See Also

Table timeouts, a similar but tangential issue