在验证时间戳（反作弊）的位置差异时，如何考虑延迟差异？ [英] Howto take latency differences into consideration when verifying location differences with timestamps (anti-cheating)?

问题描述

当您有多人游戏时，服务器正在从客户端接收运动（位置）信息，您要验证此信息是否为防欺诈措施。

这可以这样做：

  maxPlayerSpeed = 300; // = 300像素每1秒
 if（（1000 /（getTime（） -  oldTimestamp）*（newPosX  -  oldPosX））> maxPlayerSpeed）
 {
 disconnect //这是非法的！ 
} 
  

这是一个简单的例子，只考虑X坐标。这里的问题是，oldTimestamp在服务器最后一次位置更新 时存储。这意味着如果在那时存在延迟尖峰，则相对于服务器的新位置更新，旧时间戳将被接收得晚得多。

1. 客户说：我现在处于5x10位置


2. 滞后尖峰：服务器在时间戳500（通常应该到达30时）收到此消息


3. .... 1秒移动...


4. 客户说：我现在位于20x15位置


5. 无延迟尖峰：服务器在时间戳接收消息1530

服务器现在认为这两个位置之间的时间差为1030.但是，实际时间差为1500。可能会导致反欺诈检测认为1030不够长，因此踢客户端。

可能的解决方案：让客户端发送发送时的时间戳，以便服务器可以使用这些时间戳

问题：问题的解决方案是玩家可以操纵客户端发送不合法的时间戳，所以反作弊系统不会踢。这不是一个好的解决方案。

也可以简单地允许maxPlayerSpeed * 2速度（例如），但是这基本上允许速度黑客的速度是正常的两倍。这不是一个好的解决方案。

所以：你有如何解决这个服务器时间戳和延迟问题的任何建议，作弊的措施值得吗？

解决方案

没有没有没有..所有应有的尊重这是所有错误，如何不做。

解决办法是不信任您的客户。不要让客户发送他们的职位，让他们发送他们的按钮状态！查看按钮状态作为请求，客户说我向前移动，除非你反对。如果客户端发送前进消息，并且不能向前移动，则服务器可以忽略它或者做任何它喜欢的以确保一致性。在这种情况下，客户端只会骗自己。

对于通过数据包泛洪可能的速度攻击，保留一个数据包计数器。弹出在允许的设置之外的特定时间范围内发送更多数据包的客户端。客户端应该每个tick / frame / world时间步发送一个数据包。它是方便的命名数据包基于时间的整个时间步长增量。然后可以识别并忽略具有相同时间步长的过多分组。注意，使用UDP时，发送相同的包多次是一个好主意，以防止包丢失。

同样，不要信任客户端。这不能被强调。

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.

This can be done like this:

maxPlayerSpeed = 300; // = 300 pixels every 1 second
if ((1000 / (getTime() - oldTimestamp) * (newPosX - oldPosX)) > maxPlayerSpeed)
{
   disconnect(player); //this is illegal!
}

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 received 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.

Example:

1. Client says: I am now at position 5x10
2. Lag spike: server receives this message at timestamp 500 (it should normally arrive at like 30)
3. ....1 second movement...
4. Client says: I am now at position 20x15
5. No lag spike: server receives message at timestamp 1530

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.

Possible solution: let the client send a timestamp while sending, so that the server can use these timestamps instead

Problem: 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.

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.

So: do you have any suggestions on how to fix this "server timestamp & latency" issue in order to make my anti-cheating measures worthwhile?

解决方案

No no no.. with all due respect this is all wrong, and how NOT to do it.

The remedy is not trusting your clients. Don't make the clients send their positions, make them send their button states! View the button states as requests where the clients say "I'm moving forwards, unless you object". If the client sends a "moving forward" message and can't move forward, the server can ignore that or do whatever it likes to ensure consistency. In that case, the client only fools itself.

As for speed-hacks made possible by packet flooding, keep a packet counter. Eject clients who send more packets within a certain timeframe than the allowed settings. Clients should send one packet per tick/frame/world timestep. It's handy to name the packets based on time in whole timestep increments. Excessive packets of the same timestep can then be identified and ignored. Note that sending the same packet several times is a good idea when using UDP, to prevent package loss.

Again, never trust the client. This can't be emphasized enough.

这篇关于在验证时间戳（反作弊）的位置差异时，如何考虑延迟差异？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！