Re: Networking (was Re: [glob2-devel] Glob2 salvage proposal)

[Andrew Sayers]

I'm gonna go away and have a long think about ideas in a while, but in
the mean-time, some quick thoughts about things...

On Sun, Oct 23, 2005 at 09:55:02PM +0200, Stephane Magnenat wrote:
> The versioning problem is more difficult than you think: because all games 
> are 
> in sync, the problem is not only to send compatibles orders, but to ensure 
> that the execution of orders is the same everywhere, i.e. to have the same 
> engine. This is why glob2 has several version numbers: one for engine, one 
> for savegames, and one for releases. This is also why we can't use float, not 
> because we can't serlialiize them (indeed we can), but because floating 
> computation results differs on different computers (this is not fantasy, we 
> had float and we got game desynchronization because of this, so we had to use 
> int only).

Ah, that hadn't occurred to me.  Yes, that's an important issue.  Where
would floats actually be useful in the code?  If we do keep the
peer-to-peer nature of the game, it's important that we make a note of
synchronisation-sensitive files.  As Martin pointed out, avoiding floats
is no bad thing - as well as desynchronising games, they are slower than
fixed-point arithmetic, and not as useful as they sometimes seem.

> Your understanding of the interface between the network and the rest of the 
> game is correct. The latency also works as you have described. But the 
> problem is more complex that you have described. Your example was a two 
> player game. But with a four player game, for instance, any player can 
> receive or not any packet, including the ones that ask for resend or the ones 
> that tell that other players are waiting for resend, etc... This is the 
> reason why the network is so complex. When you add YOG into this scheme, for 
> the initial connection, that becomes a mess. Nuage rewrote the network 
> several times until it finally works most of the times. So my feeling is that 
> this model is just too complex to manage each case in a proper way.

Yes, I sort-of realised my previous post was underestimating the
complexity, hence the need to think about all this.  For example, it
occurred to me earlier that if every unacknowledged set of orders is
sent in every message, then receiving the acknowledgment for one
message means all previous messages can be discarded.  My instinct is
that the problems, though very complex, can be solved.  I might be wrong
though, so I'll appreciate your skepticism when I have something more to
say :)

> About your idea of directly serializing orders instead of creating objects, 
> I'm not convinced: the overhead of containing data in a struct and only 
> serializing when required is low and it is easier to debug an Order struct 
> than a bunch of bytes. Of course, we should modify the actual Orders to use 
> your new streams. Furthermore, we could also remove the switch statement that 
> chooses which order to create in favour of a registry of Order constructors, 
> adressed by the order ID, which would just be constants.

Hmm, good point.  I suspect there's a best-of-both solution where data
is directly serialised, then handlers are classes that can execute,
print, etc.  Again, I'll get back to you.

> Bye the way, we should do a developer FAQ out of those emails.. any new of 
> icclus ? If they don't answer in some days, we'll go for Kyle's proposal 
> (thanks Kyle :-)).

A FAQ would be good - as a poor man's version, I've made notes on the
Wiki of important threads, so people can use them as a resource.  Still
no news of icculus.org I'm afraid :(

        - Andrew