3 ms·

It's an exercise in time travel. The server has to maintain previous states and estimate based on lag where each client thought each other client was when the s

It's an exercise in time travel. The server has to maintain previous states and estimate based on lag where each client thought each other client was when the shot was fired. Valve has a great article on it: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking https://developer.valvesoftware.com/wiki/Source_Multiplayer_...

doomlaser 7y ago
This is the standard way of doing real-time networked multiplayer games, first pioneered by John Carmack in the Quakeworld codebase in 1996 > Instead of expecting everyone's messages to be dealt with at once, I now deal with each packet as it comes in. That player alone is moved forward in time, and a custom response is sent out in very short order. The rest of the objects in the world are spread out between the incoming packets. There are a lot of issues that that brings up. Time is no longer advancing uniformly for all objects in the world, which can cause a lot of problems. > It works, though! The average time from a packet ariving at the system to the time a response is sent back is down to under 4ms, as opposed to over 50 with the old dedicated servers. > Another side benefit is that the server never blindly sends packets out into the void, they must be specifically asked for (note that this is NOT a strict request/reply, because the client is streaming request without waiting for the replies). > I am going to be adding bandwidth estimation to help out modem links. If quake knows that a link is clogged up, it can choose not to send anything else, which is far, far better than letting the network buffer everything up or randomly drop packets. A dialup line can just say "never send more than 2000 bytes a second in datagrams", and while the update rate may drop in an overcommited situation, the latency will never pile up like it can with the current version of quake. > The biggest difference is the addition of client side movement simulation. > I am now allowing the client to guess at the results of the users movement until the authoritative response from the server comes through. This is a biiiig architectural change. The client now needs to know about solidity of objects, friction, gravity, etc. I am sad to see the elegent client-as-terminal setup go away, but I am practical above idealistic. https://raw.githubusercontent.com/ESWAT/john-carmack-plan-archive/master/by_day/johnc_plan_19960802.txt https://raw.githubusercontent.com/ESWAT/john-carmack-plan-ar...
mcbits 7y ago
Lag compensation is a (negligible?) violation of never trusting the client, as it gives the client the ability to inflate its own latency statistics until some critical moment. Not sure how reliably it can be exploited in practice, but if the stakes are high enough...
- somebodythere 7y ago
  Basically every networked multiplayer shooter has to trust the client; even if it's as basic as "did the player put their cursor over this guy's head"
  - mcbits 7y ago
    Never trusting the client just means the server must assume any messages from the client may have been manipulated or fabricated. A message like "the cursor is over this guy's head" would be an egregious mistake in the protocol because the client can easily lie about that. Lag compensation is more subtle because it's the timing between messages that may be manipulated, only for a small fraction of a second, and the client will have some uncertainty about the server's actual lag estimate. But it could be abused, for example, to trick the server into applying a "player shoots" command 50 ms earlier than it otherwise would.
- sabas123 7y ago
  This reminds me of Tribes Ascend snipers wanting to play with bigger latency because the adjustment would help them more than the lower ping.

doomlaser 7y ago

This is the standard way of doing real-time networked multiplayer games, first pioneered by John Carmack in the Quakeworld codebase in 1996 > Instead of expecting everyone's messages to be dealt with at once, I now deal with each packet as it comes in. That player alone is moved forward in time, and a custom response is sent out in very short order. The rest of the objects in the world are spread out between the incoming packets. There are a lot of issues that that brings up. Time is no longer advancing uniformly for all objects in the world, which can cause a lot of problems. > It works, though! The average time from a packet ariving at the system to the time a response is sent back is down to under 4ms, as opposed to over 50 with the old dedicated servers. > Another side benefit is that the server never blindly sends packets out into the void, they must be specifically asked for (note that this is NOT a strict request/reply, because the client is streaming request without waiting for the replies). > I am going to be adding bandwidth estimation to help out modem links. If quake knows that a link is clogged up, it can choose not to send anything else, which is far, far better than letting the network buffer everything up or randomly drop packets. A dialup line can just say "never send more than 2000 bytes a second in datagrams", and while the update rate may drop in an overcommited situation, the latency will never pile up like it can with the current version of quake. > The biggest difference is the addition of client side movement simulation. > I am now allowing the client to guess at the results of the users movement until the authoritative response from the server comes through. This is a biiiig architectural change. The client now needs to know about solidity of objects, friction, gravity, etc. I am sad to see the elegent client-as-terminal setup go away, but I am practical above idealistic. https://raw.githubusercontent.com/ESWAT/john-carmack-plan-archive/master/by_day/johnc_plan_19960802.txt https://raw.githubusercontent.com/ESWAT/john-carmack-plan-ar...

mcbits 7y ago

Lag compensation is a (negligible?) violation of never trusting the client, as it gives the client the ability to inflate its own latency statistics until some critical moment. Not sure how reliably it can be exploited in practice, but if the stakes are high enough...

somebodythere 7y ago
Basically every networked multiplayer shooter has to trust the client; even if it's as basic as "did the player put their cursor over this guy's head"
- mcbits 7y ago
  Never trusting the client just means the server must assume any messages from the client may have been manipulated or fabricated. A message like "the cursor is over this guy's head" would be an egregious mistake in the protocol because the client can easily lie about that. Lag compensation is more subtle because it's the timing between messages that may be manipulated, only for a small fraction of a second, and the client will have some uncertainty about the server's actual lag estimate. But it could be abused, for example, to trick the server into applying a "player shoots" command 50 ms earlier than it otherwise would.
sabas123 7y ago
This reminds me of Tribes Ascend snipers wanting to play with bigger latency because the adjustment would help them more than the lower ping.