Re: peer-peer syncronization

[Francesco Orsenigo <xarvh@lombardiacom.it>]

Steve Baker:
>  Francesco Orsenigo wrote:
>  This is an extremely hard thing to do - in fact, over the Internet it's
>  probably impossible.  Most commercial games give up on every single one
>  of those goals!
I was thinking about relative simultaneity, wich means that if event A and 
event B occour simultaneously for player 1 at, say, 11h45'21"pm they happen 
later or before, but simultaneously (togheter!) for player 2 at 
11h45'22"pm... If I was crossing the firing line in at the same time  my 
enemy shot, i should appear fragged on both computers...
I don't get fragged at the same time on two computers, but i get fragged when 
the enemy, on each computer, shots...
Well, i guess the fps case is easier, since there are so few MOBs....

>  "When you use UDP, you soon discover it's limitations - then you try to
>  work around them by adding error correction, timeouts, retransmits and
>  packet reordering.  Pretty soon you've implemented something thats both
>  flakier and slower than TCP."
What  a truth...

>  If you use UDP, you'd better be sending data that you can definitely
>  afford to lose.
Wich means no relative data, only absolute data (where 'relative' means that 
depends on the previous data wich must be correct...)

>  For sure. The problem is that you'd presumably be waiting for the
> responses from all other machines before anyone could start the next
> iteration.  This slows everyone down to the speed of the slowest machine.  
> If one player with a modem and a 233MHz machine joins the game from behind
> a firewall in China, people with 2GHz machines and T1 lines will be reduced
> to the same low speed.
Well, it is still good for a small LAN....

[cut]
>  That's why it's nice to have a server who can maintain the 'true' state of
> the game.  Then the other machines can get somewhat away from that state
> for short periods and be 'corrected' when the server gets around to telling
> them what's truly going on.
Yeah, but that's complex....
What about the server just 'routing' timed packets?
-The player gives a command
-The client sends the command to the server
-The server adds the time (in game time) of the execution of the command 
(maybe postponed some ticks in the future) and sends it back to ALL clients.
-The clients receive the command and, when the time has come, execute the 
command, updating the game.
Drawback: some lag between the command issued and the command executed.
But should fit a RTS game.
Or not?

>  Remember too that if you're going to use UDP, you'll be losing packets all
> over the place.  If everyone is waiting on everyone else - then one lost
> packet will stop the game...so in practice, you'd need some kind of
> time-out to allow lost packets to be retransmitted.   That would be
> workable in an asynchronous situation - but in a synchronous environment,
> everyone has to stall whenever anyone else loses a packet...that's not
> going to be much fun!
True... But how can i know how much can i trust an UDP connection?

>  The way to do things (IMHO) is to divide events in the world into things
>  that happen just once (opening a door, picking up an object, killing
> something) and events that happen continuously (moving the player, moving
> bullets, etc).
>
>  The one-time events go via TCP - they may take longer but they'll
> definitely get there.  Continuous events go via UDP and their positions are
> extrapolated on the clients to make them look like they happen smoothly.
[cut]

Maybe, but too complex for me alone.
Keeping consistency between TCP and UDP quite scares me...
I must think about it.

Thanx,
Francesco Orsenigo