Monday, May 11, 2009 at 3:20 AM |  
Time synchronization is very essential to a network game. Though for the most part, what I've read about realtime network games tend to not bother. But what they do bother was implementing client prediction to compensate network latency.

I suppose it's quite acceptable to use enet's rough estimate of round trip time. But I believe if we can improve the estimation of server client time difference, the client side prediction would be more accurate. Besides, getting a good estimate of time synchronization only takes up the first few seconds of a connection. So it's worth doing it. :)

The time sync i'm planning to implement is from this article: http://www.mine-control.com/zack/timesync/timesync.html

Though the design of time syncing is more for RTS styled network, it should still be very useful for realtime world snapshot based network.

However, implementing this time syncing algorithm requires that the internal logic code respond to the network as soon as possible. Any delay due to application layer will only jeopardize the quality of the time syncing. This being the case, I need to poll enet in a separate thread from the main rendering thread. That way, I eliminate the delay caused by any main thread's busy logic and also the beloved monitor vsync.

Then from this polling thread, whenever there's a new incoming streaming enet event, I immediately push them to the streaming thread. This gives me almost immediate event receiving for the streaming system. That way, I could implement the time syncing using the net streaming system which is a good thing. :)

However, I still need to pass normal messages back to the main thread. For that, I used a lockless queue system to queue the event messages back to the main thread without any need to do mutex locking. That means less expensive threading. Yay!

I've only just got this part compiling. Not tested yet. Hopefully it'll work. :P

P.S.
By demand, here's a list of articles I'm referencing when designing my network system:
http://fabiensanglard.net/quakeSource/index.php
http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking
http://udn.epicgames.com/Two/NetworkingArchitecture.html
http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
http://developer.valvesoftware.com/wiki/Networking_Entities
http://developer.valvesoftware.com/wiki/Lag_Compensation

P.P.S
Oh, i forgot to mention about the net streaming system during the last post. Just a quick cap, the net streaming system is a way to write synchronous network protocol in a separate thread without interfering with the main thread. This works very well for stuffs like handshake and file streaming. ;)

Lf3T-Hn4D out.
Posted by Lf3T-Hn4D

4 comments:

Anonymous said...

Could you elaborate on this "lockless queue system" of yours?
I suppose you push stuff to the queue and only check it from the mainthread when a "new junk available" flag has been toggled, or something like that?

June 5, 2009 at 6:35 AM  
Yanick Bourbeau said...

It would not be far simplier to temporary timestamp (milliseconds precision) the incoming packet then let's the game do all what he want, just before sending back a reply packet, you substract the elapsed time from the target time?

September 25, 2009 at 11:52 PM  
Lf3T-Hn4D said...

@psoul: sorry for late reply. I didn't notice your comment. Lockless queue basically is limited to two thread where one thread pushes and another pops. The internal structure uses a fixed size array of user's choice. The fixed size array is the limited maximum item in the queue. Then what we have is two pointer pointing to the head and tail of the queue. Pushing thread can only manipulate the tail while poping thread manipuates the head. You can get more info from here: http://mooproductions.blogspot.com/2006/12/lockless-queue-revision.html

@mrgibson: Yes, that's what is used for most realtime prediction. However, time syncing would help a lot better for situation where we want to trigger a specific event at a very close accurate time. Things like race countdown comes to mind. Or a time ticking bomb. ;)

September 27, 2009 at 9:10 AM  
NightCode said...

Nice knowldge and good to know ive been reading the same articles along with a gafron games? i think it was and some other site.

Something I would like to know more on is how to handle things that need to be quite accurate in an fps style game. For example a headshot, if you shoot from client a at T0 the other char might start moving at T1 on client b the server gets the move message and then the shot message client a would miss the headshot, yet player knowing it would of hit.

I suppose keeping the last two positions/times of each entity and checking them could be used?

September 18, 2012 at 2:51 PM  

Post a Comment

Liquid Rock Games and Project Aftershock. All Rights Reserved.