[MUD-Dev2] [TECH] Client time-server time sync

[Hudson, Thomas C.]

Roger D Vargas wrote:
> Yesterday I was talking to a friend and he insisted in the need of
> having perfectly synchronized server and client time, among other
> things, to calculate movements. I had thought that such thing was not
> needed, as I just need the notification of move start and figure out
> every certain time the location of player until a move stop 
> notification
> arrives. Am I wrong about this?

(Caveat: perfect isn't attainable; I'll assume you mean less than one
second, or less than a quarter second, or some other arbitrary
threshold.)

It depends on your users' tolerance for inconsistency, and how you write
the protocols. Unfortunately, I don't quite have a chunk of my
dissertation that I can cut and paste in here, but this kind of question
is where The Fun (TM) lives. There's a decent discussion of this in
Sandeep Singhal & Michael Zyda's "Networked Virtual Environments: Design
and Implementation", or in lots of old papers about NPSnet.

If you start a movement, that movement gets relayed to the server, and
the server relays it to another player, there's some delay. So let's
assume you and some other player start moving simultaneously (according
to some perfect clock, or maybe you're sitting right next to each
other). If the server just says to your client "the other player started
moving now", you'll think they started moving one-round-trip-delay after
you did, that you moved first. They'll think they moved first and that
you started moving one-round-trip-delay after they did. My understanding
is that in FPS games, this used to produce quite a bit of argument,
until Unreal (?) came along and did a bunch of correction for latency.

I believe those corrections require closely-synched clocks. I know I've
written implementations that required close synch, but those were
peer-to-peer rather than server based. Most MMOs let the server dictate
reality, have a more abstract model of combat, and tolerate occasional
jumps in character position, and so you might be able to get by without
synched clocks. But I suspect that NNTP is lightweight enough that
there's no reason not to run it, or some other public-domain clock skew
compenstion code. (Mark Mine wrote some when he was working on his
dissertation that might still be available as part of the VRPN
distribution, http://www.cs.unc.edu/vrpn).

Tom