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

[Vincent Archer]

According to Daniel.Harman at barclayscapital.com:
> From: Dan MacDonald [mailto:danmac at windows.microsoft.com]

>> My current implementation uses UDP, and I'm looking for a way to
>> determine the difference between the server time and the clients
>> time.  So that the client can have a variable that says, "Add x
>> to the current client time when comparing with times from the
>> server" I want to be able to determine what x is. SNTP does this
>> pretty well, but i dont want to be dependant on other
>> tecnologies, i'd like to build this functionality into my
>> networking layer. I was wondering if anyone had any hacked down
>> versions that could be used to synch time up to about 3-5ms
>> accuracy? Or any suggestions as to how this might be achieved?
>> (besides sending X amount of upd packets and averaging the round
>> trip times to predict the offset)

> Oops, I was about to answer this then saw your last caveat. As far
> as I know, and I've done a fair amount of research, the method you
> rule out is exactly the one everyone uses. In the end, I don't
> know of any other way to do it without piggybacking a ping on your
> packets and assuming the round trip time is symmetric.

Anybody interested in synchronising the clocks two systems and
figuring network delays should have a look at the RFC for the NTP
protocol, RFC1305, one of the few RFC that is better seen in
postscript form under a previewer or printed than in its ascii form.

Caveat: lots of equations, graphs and the like in it; there's heavy
stuff there.

SNTP itself is a stripped down version, and described in RFC2030.

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.

> 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 :)

--
	Vincent Archer			Email:	archer at frmug.org

All men are mortal.  Socrates was mortal.  Therefore, all men are Socrates.
							(Woody Allen)
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev