[MUD-Dev] Synchronizing Client and Server...

[Daniel.Harman at barclayscapital.com]

From: Vincent Archer [mailto:archer at frmug.org]

> The advantage of NTP is that it can get you to have synchronous
> client and server to accuracies of the order required, and I doubt
> anything else can be. If I remember right, NTP also detects "more
> or less" accurately assymetries in the link, i.e. it can correctly
> sync clocks when your packet takes 50ms to reach the server, but
> takes 150 to come back.

I don't doubt this is a very effective way of doing it, its just
more complex and possibly over engineered given that I don't know
any game that does this. I've forgotten EQs packet format, but I'll
have a dig later this weekend and see how they do it, I'm certain
its not anything complex. Not that I'm arguing EQ is particularly
sophisticated, but it passes the main criteria - it works. Of course
EQ isn't particularly syncronisation sensative, and now that I think
about it, they do have a bug where a client can get several seconds
out of syncronisation with the server and when you try to use a
special ability with a long refresh (e.g. 6 mins) it doesn't let
you, telling you that you have '0 seconds left before you can use
this ability'. From what I recall, they tried to fix it by setting
the client side refresh to 6mins and 6 seconds, but the problem
still appears every so often, implying 6 seconds of drift is in fact
possible. Maybe they aren't such an ideal case study ;)

>> As I mention above, you can be clever about this and piggyback
>> the timestamp onto packets with 'real' payloads etc. so that it's
>> a fairly transparent process. Try it, you'll be pleasantly
>> surprised at the results assuming your connection isn't lag
>> spiking.
 
> Real payloads and time-synchronisation don't go well together,
> unless for each payload, you are guaranteed an immediate
> response. When synchronising, you want to measure network time,
> not pathfinding time on the server :)

Well that depends on how you process incoming packets. I have
multiple threads servicing the socket, unpacking the packets and
putting them onto a queue to be processed by the main game loop. The
ping time is an attribute of the logical connection rather than an
actual game data payload, so its dealt with by the socket thread
pool threads rather than being deferred into the queue.

Even if your online game is twitch based, I suspect that advanced
ping routines with the ability to detect asymmetries etc. are over
kill. I feel the urge to go and look at the Quake 2 source code on
this. If I find time I'll have a dig and report any findings.

Dan
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev