[Freeciv-Dev] Patch to improve persistence of games

[Daniel Burrows <Daniel_Burrows@xxxxxxxxx>]

  Hi.

  I think that a bug--or at least a missing feature--in freeciv is the ability
to play games that take a long time, and in which the participants are likely
to not be connected often.  I'm attempting to address that (working from the
latest release, 1.7.2) and I'm posting the results here for comments (ie 'Great'
or 'you're wasting your time, we'll never take this', or 'you're an idiot',
or 'good but you should do XXXXX' or ' I did that already')

  My original thought was to simply wrap the Freeciv protocol in email.  I shot
this down about 5 minutes into the experment after discovering how dumb the
dumb client really is.  Sending email every time something twitches in the UI
would be too inefficient.  So I've decided instead to concentrate on
connectivity--that is, making it possible for a freeciv game to continue
uninterrupted while players disconnect and reconnect, or while the server
is shut down and brought back up.  Right now, such uptimes and downtimes seem
to be viewed in the code as an aberration, but for a game as involved and long
as Civilization, they should be par for the course.  I know that I can't
schedule a 12-hour block of time to player Freeciv.  In addition, I added a
daemon mode to the server, which will load a game file and then start the game
forked into the background. (I think that loading a game may not be necessary,
especially if there's a startup script file.  Feel free to zap that
requirement. :-) )  A lot of what I did seems slightly redundant with other
behaviors that the client and server have already, and most of it is simply
minor tweaks to logic in a few spots.  So maybe I really am wasting my time. :-)
Anyway, here's a list of what I think I changed (hopefully, nothing is left 
out..)

* "Magic cookies" - I added an authentication mechanism in which each player
                 is assigned a random 32-bit number upon connection which
                 becomes his or her authorotative identity in the game.
                 (I felt that if the games were going to continue for a
                  long time with players often disconnecting and reconnecting,
                  the player-name authentication was too insecure)
                 This is stored in the file ~/.freeciv/game; this means that
                 the patch is limited to maintining one game, but I never
                 claimed it was finished, did I? :-)  In the future, I'd like to
                 either store lots of files in ~/.freeciv or store one file
                 (~/.freecivgames?) using the nifty section-file system that
                 freeciv has.  The main reason I haven't done this yet is that
                 it requires UI tweaks to get it to work correctly, and adding
                 a "Resume" button to the connection dialog pretty much
                 stretched the limit of my Athena knowledge.
                   This makes the packet format incompatible with the vanilla
                 freeciv, so I modified the capabilities string accordingly,
                 "+MAGIC_COOKIE".  (and probably annoyed some people who tried
                 to connect to my computer from the metaserver when I was
                 testing and forgot the -n argument, then got refused because
                 of a capability mismatch. :-) )
                   If people think this is a Stupid Idea[tm] it should be
                 fairly easy for me to undo it and return to
                 playername-authentication.

                   I also added a new packet ID to support this; the packet
                 type PACKET_GAME_OVER is sent when the game terminates,
                 and the client should delete the stored authentication data
                 for that game when it's received. (I couldn't find any other
                 way to distinguish between a disconnect and the end-of-game.)
                 I think that the client-side part of this may be broken, I
                 changed the authentication filename and didn't sync it
                 in this part of the code.

                   One last change, since players might give an incorrect
                 name when connecting, the correct name is now part of
                 the join-game-reply packet.

* Server autosaving - Yes, I am aware that the server saves every X turns, so
                 this might be redundant.  The idea is to save state every
                 X _minutes_ in case something dire happens (server crash,
                 kernel lockup, etc)  The state is also saved when the server
                 exits or receives a terminal signal.  The idea is that for
                 long games, you'd tell the server to save state in, say,
                 /var/games/freeciv/ and it would be preserved across system
                 reboots and so on.  This may be a Useless Feature as well,
                 though.

* Daemon mode -     The server can now fork to the background.  Again, I'm
                 thinking in terms of being able to run an unattended server
                 for a long-term game.  If it's told to do this on startup
                 (-b commandline option), it currently requires a saved game
                 to load.  This is probably unnecessary.

* Dealing with transient connections -
                   The default behavior when a player drops connection is
                 to skip them each turn; with my patch, the game waits for them
                 to move.  This can be disabled by a server option.

  Ok, I think that's about it.  As you can see, not very many significant
changes but I've only been working on this for a day. :-)  I'm thinking that
I'd like to tackle some other obstacles to playing freeciv over a long period,
such as:


 -- handling diplomacy.
 -- displaying moves (I believe that connecting to the server after a move
   is completed just shows the new state without showing your opponent's moves?)
 -- notifying players when a move completes (merge with the above?)
 -- sending messages in the game

  I think that these could possibly be handled by reviving my idea about
wrapping FreeCiv packets in email, but I haven't looked at the code for these
sections yet so I don't know. :-)  (obviously some lag introduced..)

  Displaying the moves could be handled by storing the info about the last
move made on the server until each player has gotten it, including players
who are temporarily disconnected. (is this done already?)

  -- The ability for a client to keep multiple sets of authentication for games.



  I think that freeciv may be almost there in terms of being able to be
played the way I was thinking (connect, make moves, disconnect), but I don't
know if there are any other gotchas I should know about because I don't
know about them.

  (the major barrier to my playing a game of freeciv against a human so far
is that it's hard to coordinate matters so that you are both connected
to the server at the same time for a prolonged period of time.  I am trying to
eliminate that almost-requirement.  Maybe that's the best explanation I can
give of my goal. :-)  Of course, there is nothing stopping everyone from being
connected. :-) )

-- 
  Daniel Burrows

  Nothing is hopeless.

  PROOF:
(a) Assume the opposite.
(b) If something _is_ hopeless, then its condition can only improve.
(c) If its condition can only improve, then there must be hope for it.
(d) Therefore, nothing is hopeless.  QED.

pgpjU9heOakTh.pgp
Description: PGP signature