How to fix the xconq network code

[Hans Ronne <hronne at pp dot sbbs dot se>]

Laurent Duperval wrote:
>So what exactlky *is* the problem with the net code. Is it the code itself?
>Is it the design? Is it something else? Is it so incomprehensible that it
>should be rewritten from scratch?

The real problem is in the server-client design, as Bruno correctly pointed
out. What Stan chose to do when he wrote the network code was to have all
connected computers run the low level kernel code in parallel, rather than
running it on a server, which then tells the clients what happened. In a
way, we don't have a traditional server-client setup, but rather a bunch of
servers running in synch. In order to keep them in synch, random number
seeds are exchanged at startup. Therefore, when the AI flips a coin to
decide in which direction a particular unit should move next, the same
"random" choice is made on all computers!

This is an elegant solution since it minimizes the stuff that has to be
sent over the net. Unfortunately, the design is very sensitive to synch
errors. Even if Stan got rid of most of the bugs, some are still left. Jim
has estimated that you get a synch error every 5 turns if you run the game
in real-time (non-sequential) mode and every 20-40 turns if you run it in
sequential mode. The relative scarcity of errors is why the remaining bugs
have been so difficult to fix.

The easiest way to fix this is in my opinion to implement a more
traditional server-client setup, where the kernel code runs only on one
machine. This would for sure eliminate the synch errors, since it is
impossible for one machine to get out of synch with itself. The only
drawback would be that more data has to be transmitted over the net.
However, I don't think this is as big a problem today as it was back when
everybody was using 14K modems.

So how hard would it be to make these changes? I think not too difficult.
Already today, xconq has the ability to run all kernel code (in fact all
code whatsoever) on one computer in a network game. This is exactly how the
X11 interface (xtconq) that Jim just resurrected works. Only one program is
executing (on the host). The clients are just dumb X-terminals. Network
games using xtconq can run for more than 100 turns without any problems.
This also tells us that bandwidth should not be a problem, since all the
graphics data is transmitted in that case. A traditional server-client
setup would only transmit game data but still handle the graphics locally.
This would use far less bandwidth than xtconq does.

I think the necessary changes could be made in a relatively short time. I
have little free time in the next few weeks, but I will look into this as
soon as possible. Meanwhile, if anybody else feels like getting his hands
dirty with "plain C" code, please go ahead :-).

Hans

P.S. I agree that players need a way to communicate before launching a
game. However, we already have the chat dialog for this, and it works fine
on both the tcltk and mac interfaces. How many of you have actually tried
it? I think that if the network bugs are fixed, all we would need is a
forum page where people could post server adresses and game startup times.
This could easily be incorporated in a revised xconq home page.









Hans Ronne

hronne@pp.sbbs.se