Re: peer-peer syncronization

[Katie Lucas <katie@fysh.org>]

On Mon, Nov 10, 2003 at 05:52:35PM +0100, Francesco Orsenigo wrote:
> 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?

Yes. There will be. What you do is immediately wake up all the troops
on the player's screen and have them yell something like "Yes Sir!!!"
which will nicely fill in that gap...

> True... But how can i know how much can i trust an UDP connection?

Technically: not at all. Also, technically, there is no such thing as
a UDP connection -- connection is a TCP level thing.

Internet ones display bursty reliability. About 90% of the time 90% of
the packets will make it. 10% of the time the delivery can dip below
10%. Build a simple counter and listener and stick one end on a
machine on another continent and watch the results.

Heck, pick some remote machines and try pinging them at various times
of day.