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

问题描述

我正在使用ActionScript 3编写游戏引擎的C#Server应用程序.我正在使用权威的服务器模型以防止作弊并确保公平游戏.到目前为止，一切正常:

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滴答延迟时，当客户端移动相当长的距离时，当客户端停止时会出现明显的倾斜.如果我将延迟稍微增加到22ms，则在我的本地网络上，一切都将非常平稳地运行，但是在其他位置，倾斜仍然存在.经过一些试验后，我注意到所需的额外延迟与客户端和服务器之间的延迟密切相关.我什至将其简化为一个效果很好的公式:delay = 20 +(latency/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 noticeable 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).

因此，我将如何继续获取某个客户端和服务器之间的延迟(我正在使用异步套接字). CPU工作量不能太多，以免服务器运行缓慢.另外，这真的是最好的方法，还是有一种更有效/更简便的方法呢?

So, how would I proceed 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时间是否均匀​​，这一点很重要.如果事实证明20ms的ping时间实际上是从服务器到客户端的19ms和从客户端到服务器的1ms，则没有必要应用10ms的延迟校正.而且应用程序方面的延迟与网络方面的延迟不一样-您可以ping通一台计算机，并在20毫秒内获得响应，但是如果您要与该计算机上的服务器进行连接，该服务器每秒仅处理50次网络输入，则您的响应将额外延迟0到20毫秒，并且变化会非常难以预测.

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.

从表面上看，这里的问题似乎是您在第一条消息中发送了信息，该消息用于推断数据，直到接收到最后一条消息为止.如果其他所有条件保持不变，则第一个消息中给出的运动向量乘以消息之间的时间将为服务器提供客户端现在大致处于的正确最终位置-(延迟/2).但是，如果等待时间完全改变，则消息之间的时间将增加或缩短.客户可能知道他已经移动了10个单位，但是服务器模拟了他移动了9个或11个单位，然后才被告知将其恢复为10个单位.

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屋！