Re: [Tuxmath-devel] Networking library

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

Hi,

On Wed, Feb 16, 2011 at 2:15 PM, deepak aggarwal
<dee...@gm...> wrote:
> Hi David
> I have recently hear about a networking library on sdl mailing list. There
> they have said that this library has been used in many games. You might want
> to check it out.
> Here's the link
> http://enet.bespin.org/

I'm on the SDL list, so I saw your mailing.  I took a brief look at it
- it was written for a FPS game that uses UDP rather than TCP, because
FPS games require a lot of speed but don't care much about dropped
packets (most of the data is obsoleted by the next frame anyway).  So
I'm not sure it fits our needs so well.

More importantly, from a practical standpoint, we ought to use libs
that are included in Debian and other distros, as well as our
cross-platform setups (mingw-cross-env and MacPorts).

I looked at your diagram, and your prototype code, and unfortunately I
have no idea what you are trying to accomplish.

IMHO, our current "server" arrangement has the following limitations:
1. Each server instance can only support one math game at time.
2. Only one server instance can be run on a machine at a time.  This
can be done either in a thread from within the overall tuxmath
program, or as a standalone program.
3. When run as a standalone program, the server only runs the
compile-time defaults for the lesson settings.  There is no way to
change the lesson.  So the pthreads way is strongly preferred.
Fortunately, linux/OSX/mingw/BeOS/Haiku all provide thread support.

Now there have been comments that "the server is hopelessly broken and
should be rewritten", but I have yet to see any clear reasons why this
is the case.  It seems to be more a desire to write some elite
multithreaded/multiport server program, than anything to serve the
needs of actual users.  I have yet to have user say "the LAN game is
fun, but I wish the server supported multiple simultaneous games".

Now, on the client side, I think we have more problems.  The network
code (that is, all the calls to SDL_net functions) is supposed to be
confined to network.c/h, and I think that is the case.  Also, I think
game.c communicates with the server reasonably cleanly via the
functions in network.c/h (the ones prefixed with "LAN_").

But the server detection and game-joining is spread through four big
functions (run_lan_join(), LAN_DetectServers(), detecting_servers(),
Ready(), and Standby() in menu.c, network.c, and highscore.c).  I
think the biggest issue is that each of these functions runs its own
loop to detect network events, and there isn't any provision to
correctly handle unexpected messages or socket disconnection.  Thus,
we have a lot of "corner cases" where the client gets confused and
deadlocks or segfaults if the server connection is lost.  They won't
show up if the game is used as intended, but it isn't to hard to
deliberately cause crashes. I've started to try to fix some of these,
but this code does seem to be in need of more extensive overhaul.  In
other words, I agree we really do need a better "event system".

Just to be clear, the only reason server.c/h is compiled into tuxmath
itself is to support the running of the server inside a thread.  There
isn't supposed to be any code in those files that is needed by the
client per se.  I can see, however, that this might be confusing to
users.  Perhaps we should build and package the server and client
separately.  I think it would be pretty easy, and hopefully useful, to
create "--client-only" and "--server-only" options for configure.  The
"--client-only" version wouldn't use server.c/h, whereas
"--server-only" would eliminate factoroids.c and game.c.  Adjusting
the menus ought to be pretty easy because they are generated at run
time from the xml files.

Thoughts?

David