[Tux4kids-discuss] threads vs process in server

[David Bruce]

Hi Deepak,

On Mon, Mar 14, 2011 at 4:46 PM, deepak aggarwal
<deepak.aggarwal9 at gmail.com> wrote:
> Hi
> I am not able to decide whether i should use start new thread or fork
> a new process for every new client.

Don't you mean a new thread/process for every new _game_?

> I am thinking i should use thread as they are easier to manage and
> have very low content switching time as compare to two different
> process.
> Please help me decide between them.

I still don't understand what is the objective of your server project.
 We currently have a server that works fine for a single tuxmath LAN
game at a time.  We would like to extend it so that multiple
simultaneous LAN games can be served by a single machine.  To do this,
the server program needs to be able to handle more than one question
list (the "mathcards" stuff) at a time.  I think we should start by
modifying mathcards.c/h so that instead of having a single "global"
question list (really with file scope to mathcards.c), we have a sort
of math game "object" (i.e. struct in C) that is created for each
game, and the MC_*() functions will take a pointer to this struct as
an additional argument to specify the correct game instance.

Once mathcards.c/h properly support the concept of multiple games, it
makes sense to consider modifying or rewriting the server code to
implement it.  It _might_ make sense to do this with a thread for each
game, but I don't see that as mandatory.  The server just needs to
accept all the incoming messages, correctly determine which game they
belong to and handle them appropriately, and direct outgoing messages
to the correct clients.  To clarify - a multithreaded program may be
interesting and "cool", but we absolutely do not need to worry about
squeezing maximum performance out of a multiprocessor/multicore server
machine.

Keep in mind that network performance requirements for tuxmath are
_extremely_ low - we just send messages when the questions are
answered, and a new question is required.  Including updates of player
scores, that amounts to just a handful of 512-byte packets every few
seconds.  Coupled with the fact that we only support LAN play (not
internet, for now), I think the most ancient low-end PC has vastly
more performance than would be required to serve games to several
classrooms of players.  I don't think you need to worry about whether
threads or processes have faster context switching - just go with the
most clear-cut, least error-prone approach to the problem.

The whole thing seems to be addressing a problem that may not even
exist.  I'm not even sure the LAN mode has ever been used by schools,
and I definitely haven't had any real-life user request that we
support multiple simultaneous LAN games.  You're welcome to work on
whatever you want, but it has to be completed to the point of doing
everything the current server does before a merge into the main
program will be considered.

> I have hear about tuxadmin that is used for managing user score and
> their history. Is it still in development.

Let's say it has yet to be completed.  I don't think anything has been
done with it since last year's GSoC.

David