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

[Stephane Magnenat]

Hi Andrew,

YOG does indeed do game advertising/creation, NAT setuping and also manages 
chat rooms (but we can delegate this to IRC).

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).

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.

About having multiple orders in a packet, please note that actually glob2 put 
two orders in a single UDP packet, and thus every order is transmitted twice. 
This assures that if a single packet is lost, the network system can recover 
without any resend.

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.

To resume, the two big problems of the actual network model are:
- initialization when behind NAT and with lost packets.
- management of lost packets with several players.

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 :-)).

Thanks, have a nice evening,

Steph