Networking Progress

[Stan Shebs <shebs at cygnus dot com>]

Well, it took more than just the weekend, but the new networking code
is now generally functional and in CVS.  I'm still testing, fixing,
and adding error handling (with networking, *lots* of things can go
wrong!), but it works.  After a little more testing, I'll make another
snapshot.

The basic theory of setting up a network game is that a first player
(the "host") starts the program, then at the splash screen clicks on
"Connect".  This brings up a combined connect/chat window.  The host
player then adjusts TCP host and port to the correct host and preferred
port (defaults to 3075, which is obscurely derived from 'X' 'C'), then
clicks on "Host a Game".  If this works, then the status changes to
"Accepting Connections" and the chat area allows you to type into it.

At the same time, the other players can be starting up the program
too, clicking on Connect, and getting the connect/chat window.  However,
they need to adjust their host and values to match the host's values,
and then click on "Join a Game".  If the host game is ready by then,
then everybody connected will be informed of each successful connection,
and the joiners will also get prompts in the chat window.

Once everybody is connected, Xconq becomes the world's fattest chat
program.  Each person can type in, and will see the other players'
typing.  This is to facilitate communication for the next phase, which
is game setup.  For now, the host game will control the process,
although eventually it should be done by voting...

The host game still has the splash screen up.  The host may then
choose New or Open (which I finally implemented), and choose a game.
The joiners see their splash screen blank out, but nothing else at
this point, sorry.  When the host chooses a game and clicks OK, Xconq
proceeds to read the game as usual, then transmits it to each client.
This is still a very slow process, needs tuning, and has no feedback,
so just be patient.  When it's done, *all* players will get the
variants dialog at the same time.

Now the fun begins.  Each player gets to see and manipulate all the
controls.  In theory, any player can click on any checkbox, and the
change will appear in the dialogs of all other programs.  In practice,
it only really works right for the host game right now, but every
player will see the changes in any case.  Then the host clicks on OK
to advance to player setup.

Just as with variants, all players see the same dialog.  This time it
really does work for any player to click on any of the controls;
advantage, AI, renaming, etc.  There are currently no restrictions,
any player can modify any other player's setup bits, any number of
times, and it all seems to work.  But again, only the host can OK the
setup.

When the host OKs the player setup, all the programs launch into
the game for real.  At that point, all players can participate
as usual.

The chat window remains active through all this.  It can also be
closed and reopened at any time during the game.

Caveats: not all the error cases have been found out, if you run into
one, try to make a reproducible sequence of events to reproduce.  The
mplayer AI is somehow able to touch the kernel data without going
through the network layer, and usually causes games to get out of
sync; once a game is out of sync (there are lots of messages about
it), your best option is to save and restore.  So don't try to use
the AI yet.  Everything is slow and needs optimization.  The handling
of lines in the chat window is logical but counterintuitive; I expect
to redesign that.

								Stan