I guess the use case I am thinking of is: Client reports a hit, sends to server for clarification (or doesn't report damage til the server sends hit but does show fancy *hit* effect), server sim hasn't seen it (cos it's steps are too far apart), says no hit.
now I'm thinking this still isn't the way I want to be looking at it, but I'm not sure what is.
Okay. Due to the realities of interent latencies, at leastin the US, youa re talking latencies that are usualy in the 100ms-200ms range and jitter pretty badly, all the way up to near a second in worst cases. To make it mworse, analog modems can go into retrian mode and put as muchas 6 seconds of latency ona line.
All of this leads to an inevitable reality-- you cannot expect a tight synchronization over the net. Set two clients up next to each other for any online game and I gaurantee you that what you will see is a pretty loose synch. Thats just reality.
So sicne you cannot closely synch, you don't try. You design your game as open loop and loosely synchronized. As long as the simulation on each persons terminal is reasonable and fair, they dont have to be identical. Now there are a few times when POV becomes critical, mostly these are interractions like shooting someone or hitting them. The schemes for that vary.
Most first person games take advantage of the fact that the only person who has any great amoutn of information on aiming is the shooter. based on that, you can let him decide if its a hit. The one problem with this as a complete solution is it leaves the cleitn open for cheating. One way to sovle this is to move shooting to the server. This works though you risk having shots thata re dead on on the lcients side miss in the server's view. Another solution is to let the client decide but have the sevre checkign for "reasonableness". If the serve decides there is no way a hit could have happened thatis being reported, it decides the client is cheating.
Now buried in this whole discussion is really the question of position. Im going to pull it to the front because it helsp illustrate a difference you cna take advantage of between client and server. The client has to be correct ona frame by frame basis. Thsi means that it indeedneeds to si,ulate ona frame by frame basis. The Server though just needs to detect the client cheating and resolve such questions as "where was object X at time Y". With any object that moves in straight lines (or actually in a mathematically predictable curve, straight is just the degenrate case) if you know some information at two end points, you know every postion the object was in between these end points.
I dont actually need to process the entire shot when its fired if I can ask the question later "at this time could this object have hit that object with a shot." Cheat detection doesnt have to be immediate as long a its reasonably soon after the fact. All you cna do with a cehater anyway is (a) reset the game to befoe the cheat and/or (b) kick him or her out.
BattleTrollS/JNWN takes advantage of this, as we demoed at the show. We send a message to the server whenevr our movement state changes-- this means start, stop, or chnage angle. The server does a line segment test vs the walk mesh to check all the points in between. If it intersects a wall or other unwalkable, we tport the player abck to the start position of that ssegment.
(We actually limit the angle change messages to a min-change to avoid flooding the server. We also send an update periodically even if we are just walking straight so lag doesnt get too extreme.)
I hoep this helps get the ideas flowing anyway.