Note that there are some explanatory texts on larger screens.

plurals
  1. POHowto take latency differences into consideration when verifying location differences with timestamps (anti-cheating)?
    text
    copied!<p>When you have a multiplayer game where the server is receiving movement (location) information from the client, you want to verify this information as an anti-cheating measure.</p> <p>This can be done like this:</p> <pre><code>maxPlayerSpeed = 300; // = 300 pixels every 1 second if ((1000 / (getTime() - oldTimestamp) * (newPosX - oldPosX)) &gt; maxPlayerSpeed) { disconnect(player); //this is illegal! } </code></pre> <p>This is a simple example, only taking the X coords into consideration. The problem here is that the oldTimestamp is stored as soon as the last location update was <strong>received</strong> by the server. This means that if there was a lag spike at that time, the old timestamp will be received much later relatively than the new location update by the server. This means that the time difference will not be accurate.</p> <p>Example:</p> <ol> <li>Client says: I am now at position 5x10</li> <li>Lag spike: server receives this message at timestamp 500 (it should normally arrive at like 30)</li> <li>....1 second movement...</li> <li>Client says: I am now at position 20x15</li> <li>No lag spike: server receives message at timestamp 1530</li> </ol> <p>The server will now think that the time difference between these two locations is 1030. However, the real time difference is 1500. This could cause the anti-cheating detection to think that 1030 is not long enough, thus kicking the client.</p> <p><em>Possible solution</em>: let the client send a timestamp while sending, so that the server can use these timestamps instead</p> <p><em>Problem:</em> the problem with that solution is that the player could manipulate the client to send a timestamp that is not legal, so the anti-cheating system won't kick in. This is not a good solution.</p> <p>It is also possible to simply allow maxPlayerSpeed * 2 speed (for example), however this basically allows speed hacking up to twice as fast as normal. This is not a good solution either.</p> <p>So: do you have any suggestions on how to fix this "server timestamp &amp; latency" issue in order to make my anti-cheating measures worthwhile?</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload