我如何获得在C＃中的服务器和客户端之间的延迟 [英] How do I obtain the latency between server and client in C#

问题描述

我工作的一个游戏引擎，我在ActionScript 3写我使用的权威服务器模式，以防止作弊，并确保公平的游戏一个C＃服务器应用程序。到目前为止，一切正常：

I'm working on a C# Server application for a game engine I'm writing in ActionScript 3. I'm using an authoritative server model as to prevent cheating and ensure fair game. So far, everything works well:

在客户端开始移动，它告诉服务器并启动本地渲染;服务器的话，告诉其他人该客户端X已经开始移动，用细节中如此他们也可以开始渲染。当客户端停止运行，它告诉服务器，它执行基于客户端开始移动并在客户端渲染剔延迟和回复给大家时间计算，这样他们就可以用正确的值更新。

When the client begins moving, it tells the server and starts rendering locally; the server, then, tells everyone else that client X has began moving, among with details so they can also begin rendering. When the client stops moving, it tells the server, which performs calculations based on the time the client began moving and the client render tick delay and replies to everyone, so they can update with the correct values.

的事情是，当我使用服务器上的计算默认20ms的滴答的延迟，在一个相当长的距离客户端移动，有一个noticable向前倾斜时，它停止。如果我延迟略有增加至22毫秒，我的本地网络上的一切运行速度非常流畅，但在其他地方，倾斜仍然存在。实验一点点后，我注意到，所需的额外延迟是非常依赖于客户端和服务器之间的延迟。我甚至煮它归结为一个公式，将工作相当不错：延迟= 20 +（延时/ 10）

The thing is, when I use the default 20ms tick delay on server calculations, when the client moves for a rather long distance, there's a noticable tilt forward when it stops. If I increase slightly the delay to 22ms, on my local network everything runs very smoothly, but in other locations, the tilt is still there. After experimenting a little, I noticed that the extra delay needed is pretty much tied to the latency between client and server. I even boiled it down to a formula that would work quite nicely: delay = 20 + (latency / 10).

所以，我怎么会procceed获得之间的延迟。一定的客户端和服务器（我使用异步套接字）。该CPU的努力也不能太多，以没有服务器运行缓慢。此外，这真的是最好的办法，还是有一个更有效/更简单的方式做到这一点？

So, how would I procceed to obtain the latency between a certain client and the server (I'm using asynchronous sockets). The CPU effort can't be too much, as to not have the server run slowly. Also, is this really the best way, or is there a more efficient/easier way to do this?

推荐答案

遗憾，这没有直接回答你的问题，但总体来讲，你不应该过分依赖于测量延迟，因为它可以是相当变数。不仅如此，你不知道，如果你测量的ping时间更对称的，这是非常重要的。有没有申请延迟修正为10ms点，如果事实证明，20毫秒的时间平实际上19ms从服务器到客户端和1ms的从客户端到服务器。而在应用方面的延迟是不一样的，因为在网络术语 - 你可能能够ping某台机器，并在20毫秒得到回应，但如果你接触的机器，只处理网络输入上的服务器50次，然后第二你的回答将通过一个额外的0至20ms的延迟，这将相当不可预知的变化。

Sorry that this isn't directly answering your question, but generally speaking you shouldn't rely too heavily on measuring latency because it can be quite variable. Not only that, you don't know if the ping time you measure is even symmetrical, which is important. There's no point applying 10ms of latency correction if it turns out that the ping time of 20ms is actually 19ms from server to client and 1ms from client to server. And latency in application terms is not the same as in networking terms - you may be able to ping a certain machine and get a response in 20ms but if you're contacting a server on that machine that only processes network input 50 times a second then your responses will be delayed by an extra 0 to 20ms, and this will vary rather unpredictably.

这并不是说延迟测量它不具有平滑预测的地方出来，但它不会解决你的问题，只是清理了一下。

That's not to say latency measurement it doesn't have a place in smoothing predictions out, but it's not going to solve your problem, just clean it up a bit.

在它的面前，这里的问题似乎是，你是发送其中用来从直到收到最后一个消息推断数据在第一消息中的信息。如果一切都保持恒定则第一消息乘以消息之间的时间在给定的运动矢量将给出服务器的正确结束位置，客户端是在大致NOW-（延迟/ 2）。但是，如果延迟变化可言，消息之间的时间将增长或收缩。客户端可以知道他搬到10个单位，但服务器模拟他被告知要扣他回10台移动之前9或11个单位。

On the face of it, the problem here seems to be that that you're sent information in the first message which you use to extrapolate data from until the last message is received. If all else stays constant then the movement vector given in the first message multiplied by the time between the messages will give the server the correct end position that the client was in at roughly now-(latency/2). But if the latency changes at all, the time between the messages will grow or shrink. The client may know he's moved 10 units, but the server simulated him moving 9 or 11 units before being told to snap him back to 10 units.

一般的解决这个是不是认为延迟将保持不变，但要定期发送位置更新，允许服务器验证和纠正客户的立场。只需2消息作为你现在，所有的错误被发现，第二个消息后更正。随着更多的消息，误差分布在更多的采样点，允许更顺畅，不太明显的校正

The general solution to this is to not assume that latency will stay constant but to send periodic position updates, which allow the server to verify and correct the client's position. With just 2 messages as you have now, all the error is found and corrected after the 2nd message. With more messages, the error is spread over many more sample points allowing for smoother and less visible correction.

它不可能是完美的，但：所需要的是一个滞后秒杀在运动中的最后一个毫秒和服务器的代表将冲过。你不能得到解决，如果你预测未来的移动基于过去的事件，还有在选择没有真正的替代改正，但后期或不正确的，但是，由于及时的信息需要时间去旅行。 （怪爱因斯坦。）

It can never be perfect though: all it takes is a lag spike in the last millisecond of movement and the server's representation will overshoot. You can't get around that if you're predicting future movement based on past events, as there's no real alternative to choosing either correct-but-late or incorrect-but-timely since information takes time to travel. (Blame Einstein.)

这篇关于我如何获得在C＃中的服务器和客户端之间的延迟的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！