As I understand, when a packet is sent to a computer in the IP protocol, it follows a path from SENDER -> ROUTER-a -> ROUTER-b -> ROUTER-x -> DESTINATION. Routing determines what path a packet takes, to get to a host.
I’m currently developing a game, with multiplayer networking, using UDP. Since the game is realtime, I need to effectively rollback the physics world, every time a packet is received, to determine what the client did, when they saw it happening. To do this, I must rollback the physics world, n-seconds, where n is the time is took the packet to travel from client to server. Latency is dynamic (I think, correct me if I’m wrong).
To optimize this process, I’m wondering if it would be possible, for a packet always to take a static route, so I can determine a static latency for the client.
I think the fundamental assumption embedded in this question is flawed. Packet latency doesn’t fluctuate because the routed path changes (granted, this does have an effect when it happens, but it’s not a frequent occurrence on the net) but rather due to other factors like congestion and data coalescence.
Your basic enemy is really packet congestion rather than route switching, as far as latency and unfortunately, there’s no way to stabilize either one perfectly, as they both rely on factors beyond your control. Route switching is done by policy, which can just as easily deny any request of yours to establish a fixed route.
Above all, keep the client in the know. If they chose a server with 800ms latency, they should know their game experience will be very poor. Where possible, make the choice automatic to find a low latency server for them to use.
Cheat Proof Algorithms
This kind of question hints at making a “cheat proof” algorithm by establishing a baseline latency, and saying that any significant fluctuation is cheating. That’s not a bad algorithm in theory, but it doesn’t work well in the real world, as latency varies WIDELY due to factors beyond our control as programmers.
The only tools really available to you are to ensure the commands being sent aren’t wildly outside the game’s legal parameters, and bumping any excessively delayed action up to the maximum allowed limit time, or dropping them entirely. In a time sensitive game especially, if the client lags out for 10 seconds, it’s unlikely their actions will still be relevant.
Streaming Applications
The reason we use stream buffers is because of the unpredictability of latency. If your latency flux is large, your stream buffer must also be. Inversely, if your latency flux is very small, the stream buffer can be small as well. For applications like VOIP, we like to keep the buffers as short as possible, but there’s always a trade off between the size of the buffer relative to the flux, and the probability of distortion caused by buffer underflows.
Your specific need may be different from either of these two, so your solution may end up being different. Just keep in mind that you’re never going to be able to control latency 100% unless you control the network from end to end. (IE: you’re not using the internet to transport data)