Reconnection and recovery

Though it's not on the roadmap (yet) I definitely want to have 
reconnection ability in the protocol and implemented in Frivolity this 
month.

The client side is the easy part. See my proposed protocol here: 
http://www.volity.org/wiki/index.cgi?State_Recovery

In a nutshell, the client can, at any point, send a RPC request called 
volity.get_full_state() to the referee. It responds by calling a 
sequence of ordinary ruleset-specific RPC requests back on the player, 
tailed with a volity.state_sent() request to show that it's finished.

The more complicated part involves how referees should react to players 
abruptly leaving the table. There are several ways I think of to handle 
this, such as:

1. The referee just sits and waits indefinitely for the player's 
return. The returning player must have the same JID as the lost one. 
The simplest solution. Also, the lamest.

2. The referee waits for some amount of time for the same-JID-player's 
return (perhaps determined by table configuration) and then kills the 
game. It tells the bookkeeper that the player cut out.

3. As above, except that the ref plops a bot in the lost player's seat. 
It still tells the bookkeeper that the player cut out, and lets the bot 
take credit appropriately.

4. The referee remembers how many seats were filled (lets call this 
number S), and then sets all players' status to 'unready', preventing 
any further play. The game resumes when S seats are occupied AND all 
players are ready -- this is only possible if whoever sat in the 
vacated seat (which may or may not be the original player) is an 
acceptable replacement to everyone else. (It also allows players to 
manually replace the lost one with a bot, or for additional players to 
leave and be replaced with others.)

Yes, I did in fact just think of option (4), and it does in fact force 
resolution of the whole roles & records issue (on which I will have 
more to say shortly). I kind of like it, though it has the problem of 
someone sabotaging a game by an unacceptable sitting down and refusing 
to leave. This seems too pointless to worry about, though, and solvable 
by giving the original players access to MUC-level "boot" commands.

Thoughts?

--
   Jason McIntosh             jmac <at> jmac.org
Somerville, MA, USA       http://www.jmac.org

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt