Re: [Tuxmath-devel] Help needed on tuxmath server created by you

[David B. <dav...@gm...>]

Hi Deepak,

This ought to go to the tuxmath dev list instead of just me and Akash
(cc'd).  Coincidentally, I've worked on the LAN game in game.c the
last couple days and am about to push a significant change to git.
Basically I'm getting rid of the "question queue" on the client side
so that questions appear immediately when received from the server,
and will have the server decide when the next wave starts, etc.  The
idea is to keep the questions as simultaneous as possible for all
players so gameplay will be fair.

On Wed, Jan 26, 2011 at 2:55 AM, dee...@gm...
<dee...@gm...> wrote:
> Hi akash
> I am working on common lib of server for tux4kids. Could you please give me
> a layout how server work in tuxmath. I am also working on common libraries.

The server code is in tuxmath's server.c/.h.  The code for the client
to connect to the server is in network.c/.h.  This code is used in
game.c for the LAN game, and in menu.c and highscore.c for the menu
entries related to LAN play.

> I am attaching server side code.
> Features:
> 1. Dynamically allocate port no to client so that multiple client fan
> connect to server.

That means we need to have as many ports as we have active lan games
on the server.  Is this what network apps normally do?  I think we
could have a multithreaded server (see below) but still have all the
clients connect through the same port.

> 2. It isn't yet multithread but it is half done.

By all means, join our project on alioth and create a git branch for this.

My thoughts on having the server support multiple games:
1.  There are lots of ways to potentially do this.  Right now, the
server can be run as a thread within tuxmath or as a standalone
program.  The thread way has a lot of advantages, namely that we can
make use of the existing code to set the "lesson" file to be played by
the server game.
2.  Mathcards.c is not thread-safe.  It assumes one "math game" at a
time.  However, it could be modified with just a bit of effort to
support multiple "games", which would mean that all the MC_* functions
would get an extra argument to identify the particular game.  Each
game would have its own question list, and there would be very little
(if any) data that would be shared between threads and hence require
locking.  So I don't think it would require any really hairy
multithreaded programming.  I think this needs to be tackled before we
can make the server itself support multiple games.

There are more things I could bring up but I have to go to work now.

Thanks,

David