This is an old question but I've worked out similar code recently so maybe this will help someone.
Yes latency is always useful in the calculation. But it is slightly more complex than RTT. Round trip time is always changing... your network code can keep an average, but the variance from that average is large.
The local client, remote client, and server all predict the current position using algorithms. The following data is close to typical:
- Time: t
- Placement: Position (x,y,z) and Orientation (x,y,z,w)
- Movement: Linear movement vector giving direction with length as speed (x,y,z), and
rotational movement vector giving axis with length as rotational speed (x,y,z)
You need the algorithms that extrapolate from a [T,P,M] set to the simtime. I won't be providing those here.
When the client registers a change in the drive of the ship at [T,P,M], that wont get to the server until T+deltaT. But if deltaT is within the tolerance of typical network latencies, the server can say "Yes it happened at T, I accept that." Otherwise it might want to correct the client saying "No thats out of tolerance, it happened at my time T' " in which case the client will have to REPLAY all the subsequently driven [T,P,M] changes from the server's corrected one (meaning you need to keep a queue or list of them).
The next client will get it at T+deltaT+differentdeltaT. It can't possibly change what it has already simulated, so if it isn't delaying it's simulation it will jump the remote ship and you will see a jerk frame. That's why remote driven ships should have their simulations delayed by a time consistently greater than 2*typicaldeltaT. It should be a constant delay, or a delay that changes gradually, and in times of severe lag you will see jerk frames nonetheless
You can smooth all jerks with extra smoothing code but don't do it until your code is otherwise flawless because it will just make it impossible to see where the problems are.
You must have a good synchronized time reference. A lot of code out there does it rather sloppily (e.g. RakNet doesn't (or didn't) do it very well). Here's a good hint: in the short run you can presume that everyone's clocks are running at the same rate, and you only need to figure out what the offset is, so keep a window of maximum and minimum offset and close it as you learn; In the long run you need to compensate for clients whose clocks are running fast or slow, so allow the window to open if you know for sure it must. You must use a local timesource that is monotonically increasing and not keyed off of the processor speed (which nowadays is variable).
No, don't delay the local simulation when the local "avatar" moves. It would seem way too unresponsive. You could delay it slightly (up to maybe 50ms) to help improve synchronization, but a delay all the way out to the RTT would make your game seem frustratingly unresponsive. Set an option for local delay and play with it, because a small consistent delay can be acceptable and improve synchronization. But it's not necessary and can cause lots of problems so I recommend doing that code last. (If you are trying to do a FPS melee game, you'll need to do this and all the other help you can get).
As for cheat prevention vs. simulation smoothness: First, the clients shouldn't just extrapolate from the last known position, when the official position changes. It should register an adjustment vector and slowly move from the old path to the new path for smoothness (but like I said above do this code last or it will mask other bugs). Secondly, the server should tolerate a wide range of delays... even on machines on the same ethernet the packet delay typically runs 5ms to 100ms or so... that is quite a range. Of course you need to cut it off and say "if you say you moved at time T but I got the packet at T + some_large_number then I think you are trying to adjust the past and lying to me." some_large_number shouldn't be much bigger than the average RTT to keep people honest.
The simulations will never be tightly synchronized. They should stay within 400ms or so over the Internet but certainly will stray outside of that during times of lag... to 30 seconds or more, and you need to tolerate things that that because they aren't rare. Given that the Internet is limited by the speed of light in copper, you can always expect one-way latencies to typically be in the range of at least 100ms minimum for your far clients, often 500ms or longer.
Therefore I highly recommend you don't try to make a melee FPS game over the Internet (some big companies try but will always have troubles). There are tricks you can do if you are using projectiles (by running them fast in one simulation and slow in the other) so that even though the timing is off, it looks on. Also, FPS games use the rule that hit-detection is based on the attackers simulation... it feels more wrong when the attacker knows he was dead on target and misses, then when a defender knows he was out of the way and gets hit anyways. You have to choose one or the other, and psychologically that's how it's been done. Melee requires a level of synchronization which is frankly impossible and most game companies won't touch MMORPG FPS melee but rather use auto-targetting (try playing Mortal Online, you will see what I mean).
Good luck.