在类似在线农场的游戏中,我需要验证服务器客户端的长期过程,如建房。说房子需要10分钟才能建成。客户端在开始构建房屋时以异步方式发送“开始构建”消息,并在认为房屋建成时“完成构建”。在服务器上,我需要验证房子至少在10分钟内建成。问题是服务器不知道客户端何时发送“开始构建”和“完成构建”消息。它知道何时收到消息,但是存在网络延迟,可能的网络故障和消息可能足够长以占用几个tcp段。据我所知,客户端发送消息的时间可能长达几分钟,具体取决于客户端的TCP配置。问题是:有没有办法知道客户端何时发出消息?如果没有,我如何保证发送该消息的时间段,可能是某些服务器TCP配置?该服务器中的某些超时要么接收消息,要么失败就可以了。我也许不会考虑任何其他主要任务的解决方案。
提前致谢!
答案 0 :(得分:1)
如果我理解正确,你的主要问题与TCP本身无关(因为描述的场景也可能发生在使用UDP),而是与你的消息的时间顺序有关,并确保时间线没有被伪造。
因此,您要避免的唯一情况如下:
STARTED send at 09:00:00 and received at 09:00:30 (higher latency)
FINISHED send at 09:10:00 and received at 09:10:01 (lower latency)
因为它看起来像服务器,好像只花了9.5分钟构建你的虚拟建筑。但是客户并没有作弊,只是第一条消息的延迟时间比第二条消息更高。
反过来也没问题:
STARTED send at 09:00:00 and received at 09:00:01 (lower latency)
FINISHED send at 09:10:00 and received at 09:10:30 (higher latency)
或
STARTED send at 09:00:00 and received at 09:00:10 (equal latency)
FINISHED send at 09:10:00 and received at 09:10:10 (equal latency)
在收到两封邮件之间至少经过了10分钟。
不幸的是,没有办法确保客户端不会使用时间戳等作弊。如果您的客户端在消息中写入时间戳或者协议是否为您执行此操作,则无关紧要。这有两个原因:
所以唯一可以肯定的是服务器收到消息的时间。一个简单的解决方案是,如果服务器认为在收到FINISHED消息时没有足够的时间,则发送一些包含留给客户端的时间的RETRY消息。因此,客户可以调整构造动画,然后再次发送FINISHED消息,具体取决于剩余的时间。