If I understand it correctly, here's how it would work. Feel free to correct me if I'm wrong.
Let's assume just for grins and because I like round numbers, .25 second latency for all parties concerned.
I'm flying along, something happens.
0.25 seconds for me to react to it.
0.25 seconds for my input to get to the server.
0.25 seconds for my input to make it back to all clients, including my own.
Since it would take 0.5 seconds for my inputs to be transferred into motion of my plane, effectively there'd be a 0.5 second delay on gunnery. That's pretty noticeable, and that's assuming a pretty decent ping. Wouldn't that be much worse than what we have now?
Even if we assume 0.125 ping, that's still going to double reaction time.
Wiley.
Your latency is typically the full round-trip time (otherwise, your .25s travel time would actually be a .5s latency, which is horrible by any standard). Most users have a latency of .3 or less (which means 150ms or less both ways).
Now, yes, if you're flying straight and level and you waited for some kind of queue to move your joystick (whether it's a barrage of bullets, an oncoming plane, etc.), then yes, you'd have your reaction time coupled with your latency. However, that's not how it functionally works.
Due to latency, you're ALWAYS flying current time minus latency. Let's assume a latency of .2 seconds (200ms, which is getting somewhat close to the high side). This means that you're flying .2 seconds in the past for ALL of your maneuvers... and so is your opponent. Your opponent is also seeing you .2 seconds in the past... all the time. When both planes are reacting .2s in the past, then they're effectively flying the same as they would in the present. In most cases, it's unnoticeable.
You're not flying with your hand off your stick and then quickly grabbing it in a dogfight - you're constantly making adjustments (that's what dogfighting is). It's natural, so the only "reaction" time you need is the visual queue, which corresponds with latency. As long as the plane you're watching/fighting against has a latency of less than 1/3 a second or so, you're fine, because what you see on the screen corresponds to what is happening in real time (as the average human can't easily detect changes that happen faster than 1/3 a second or so). Even if you could, WWII aircraft are not that responsive, so it fits this genre of games just fine.
Therefore, latency isn't an issue when 1) it's relatively low (under 1/3 a second or so) and 2) the players have similar latencies, as
experienced latency ends up being the difference between the individual players' latencies in relation to the reference connection. This is important.
Why? Because the reference connection on a server-based solution is, you guessed it, the server. So if one player is connecting to the server at 100ms and another at 150ms, then the perceived lag will be 50ms (which is virtually undetectable by humans).
However, when using a client-based solution, the server is no longer the reference point, so perceived "lag" occurs whenever two players encounter something that doesn't match exactly on both ends, as you have no common reference point or standard. This usually ends up benefiting one player while putting the other (or others) at a disadvantage.
This is why server-based systems are in place for most all competitive/professional games.
