Well, I do apologize for the negativity regarding MMORPG development. There’s nothing wrong with walking down the long road that is developing an MMO, of course; and you have all of my encouragement. I understand how discouraging it can be that the internet appears to be filled with people trying to tell you how hard it is. On the flip side, the internet also appears to be filled with people who have absolutely no idea how hard it is; and no doubt the negativity is a reaction to this naive enthusiasm.
Now, to your specific questions. I’ll answer the last one first, since this is useful to understand the rest:
What is Uncertainty and trust?
Uncertainty is the number that indicates how precise your measurement of server time is. You should understand that no two clocks are ever precisely in sync, and you also cannot know precisely how far out of sync you are. If the server sends a message to the client saying it is precisely 12:00, by the time the client receives the message, it is already out of date. Since you don’t know precisely how long it took for the message to get from the client to the server, you don’t know precisely how far out of date it is, and therefore the client doesn’t know precisely what time it is on the server right now.
But you can put an upper bounds on time it took to receive the message. For instance, suppose the client starts a timer, then sends a message to the server asking what time it is. When the server receives this message, it immediately sends a response to the client indicating the server’s current timestamp. When the cilent receives this response, it stops its timer and looks at how long the round-trip message took.
That round-trip message time is the uncertainty. The server responded sometime after the first message was sent from the client, so you know that the message can’t be more than n seconds old. (You could guess that both messages took the same amount of time to send, and assume that the message was exactly n/2 seconds old, but this wouldn’t be realistic. In fact, some messages take a lot longer to transmit than others.)
Once you have a measure of the uncertainty, you can say that your client’s clock is in sync with the server, +/- n seconds.
The trustNew parameter to resynchronize() just describes what to do if the new time measurement is completely different from the previous one. If trustNew is True, then the previous time measurement is discarded, and the new one is accepted. If trustNew is False, the previous measurement is kept, and the new one is discarded. See peerToPeerResync, below.
I don’t know. How much clock drift can your application tolerate? Any two clocks, once synced, will gradually drift apart from each other. That is to say, over time, the uncertainty will gradually increase. Thus, you have to sync occasionally to keep them from drifting too far apart. The frequency of resync depends on two points: (1) the rate at which your two clocks are drifting apart, and (2) the tolerance your application has for clock drift.
In practice, probably a resync every 30 minutes or so will be more than sufficient.
This method is used internally by resynchronize(). You normally wouldn’t call it directly.
If your application involves any direct communication between peers (two or more clients, as opposed to only client-server communication), then you can use this method to pass a sync from one client to another. This is a little less good than receiving a sync directly from the server, because you inherit the uncertainty from the other client, plus the uncertainty of the network communications. But it’s conceivable that client A can’t get a good reliable connection to the server, but he can get a reliable connection to client B, and client B can get a reliable connection to the server.
Of course, since the other clients might be lying (in any MMO, you can’t trust any of the clients, since they might be corrupted by hackers), peerToPeerResync automatically passes trustNew = False.
On the whole, though, peerToPeerResync is a little esoteric.
David
