使用SFML在实时网络上验证发送的数据包 [英] Verifying sent packets on real time network using SFML

问题描述

我正在构建一个可联网的程序，该程序可以使用SFML UDP库在2D屏幕上传输图形更改.

I am building a networkable program that transfers graphical changes on a 2D screen with SFML UDP libraries.

我想在主机服务器上运行所有处理，并且只将图形更新和命令返回值发送给客户端.

I want to run close to all of the processing on the host server, and only send the graphic updates and command return values to the client.

我想在将数据发送到连接两侧的屏幕之前进行验证.我正在考虑发送单个字节为0或1，以表示成功接收数据并进行同步.

I want to make a verify condition before the data is sent to the screens on both sides of the connection. I was thinking about sending a single byte as either 0 or 1 to represent successful reception of the data and to synchronize.

(见图)

    Server-------( updates )----->Client  
       |                             |  
  ( wait for )<---( 1 or 0 )-----Send Byte  
       |                             |  
    ( if 1 )                ( if byte received )  
       |                             |  
    Screen                        Screen  

在更新屏幕之前来回往复以确保两端都验证了数据似乎是合乎逻辑的，然后随后再次运行同一事物的另一次迭代(当然是无限期地).

It seems logical to ping back and forth to make sure the data was verified on both ends before updating the screen and then subsequently running another iteration of the same thing (indefinitely of course).

我的问题是，使用SFML，发送1/0是否有意义，还是会自行验证，即.发送数据时返回值?

My question is, using SFML, is there a point in sending the 1/0, or will it verify on its own, ie. with a return value when the data is sent?

此外，通过网络发送该字节比进行其他操作(例如尝试按时间同步)是否更慢?使用FPS也许有更好的方法吗?

Also, is it slower to send that one byte over the network rather than doing something else, like trying to sync against time? Is there perhaps a better way to do this with FPS?

关于SFML的答案可能是最好的.

Answers in terms of SFML will probably be best.

推荐答案

如果要使用UDP模拟TCP，为什么不使用TCP?

如果您坚持使用UDP，因为性能可能很关键(即使您认为性能很关键，TCP可能会完成这项工作)，则客户端应发送其命令/更改/数据，并且仅对收到的数据做出反应永远也不必发回布尔值(或单个位)，因为有更好的方法来处理此问题，这对整个数据包来说是很大的浪费.

If you're going to simulate TCP with UDP, why not use TCP?

If you're adamant on using UDP as performance is maybe critical (and even if you think performance is critical, TCP will probably do the job), your client should send its commands/changes/data and only react on received data and never bother sending back a boolean (or single bit) as there are better ways to deal with this and it's a big waste of a whole packet.

1. 如果客户端从未收到请求的特定返回值，只需在给定的时间阈值后将请求重新发送到服务器，并希望获得最好的返回值.
2. 如果客户端没有任何更改，并且服务器没有任何内容，则只需重新绘制屏幕(或等待客户端更改)
3. 如果在重新发送一个或多个请求后服务器没有任何响应，请将该问题告知客户端. (连接丢失或服务器错误)

按照我的描述，服务器只需要响应一次来自客户端的请求，然后就不必理会它.

In what I'm describing, the server only has to respond to requests from a client once and then forget about it.

1. 如果服务器从未收到请求(因此也从不响应客户端)，则客户端仍将发送回其请求.
2. 如果服务器和客户端之间的服务器响应丢失，则客户端将在时间阈值之后再次将其请求发送回服务器.

由于我们缺乏有关您要实现的项目的信息，因此很难为您提供正确的解决方案.

It's hard to give you the right solution as we lack information on the project you're trying to achieve.

但是，可以说这是一个游戏.

But let's say it's a game.

在游戏中，您将不信任客户端，因此玩家执行的每个命令都会发送到服务器.服务器处理命令，进行所有计算并跟踪整个游戏的所有玩家.

In a game, you wouldn't trust the client, so every command the player does is sent to the server. The server handles the command, does all the calculation and tracks all players for the whole game.

然后，服务器将新职位返回给客户端.客户端仅显示来自服务器的更改.例如，客户端从不在键盘输入上移动播放器.输入直接按原样发送到服务器，客户端从服务器接收一个新位置，移动指定的图形，然后渲染到屏幕.

Then, the server returns the new position to the client. The client only displays changes coming from the server. For example, the client never moves the player on a keyboard input. The input is simply sent to the server as-is and the client receives a new position from the server, moves the designated graphics, then renders to the screen.

就是这样.

实际上，现实世界中的游戏客户端会处理输入，并尝试在向服务器发送请求之前/期间内插更改，然后根据接收到的数据进行调整.即使没有网络通信不可避免的延迟，这也会带来没有延迟的幻觉.延迟仍然存在是因为数据包由于连接不良或间歇性延迟而丢失，但是插值仍然有帮助.

In fact, real world game clients handle inputs and they try to interpolate changes before/while sending requests to the server and then they adjust from the received data. This gives the illusion of absence of lag, even with the inevitable delay from network communications. Lag still exists because packets get lost on poor connections or intermittent latency, but interpolation still helps.

有了这个，您仍然不信任客户端，只是在服务器响应之前猜测.

With this, you still don't trust the client, you're just guessing before the server responds.

这些策略与协议无关，因为您可以自己处理问题.

The strategies are protocol agnostic, as you're handling the problems yourself.

如果您要发送大量仅与发送时间相关的数据，则UDP将完成此工作.想想视频会议或语音聊天，当您丢失数据包时，将其发送回已经为时已晚.

If you're going to send a lot of data that is relevant only for the time it is sent, UDP will do the job. Think video-conference or voice chat, when you lose a packet, it's already too late to send it back.

如果您要发送适量的信息(例如仅每秒发送60次)，则接收顺序可能比带宽或延迟更重要，因此TCP可能是解决之道.

If you're going to send moderate number of informations, like only the position 60 times a second, maybe the order of reception is more important than bandwidth or latency, so TCP might be the way to go.

如果要使用单独的服务器应用程序，则不要使其也显示在屏幕上，只需在服务器计算机上运行另一个通过本地主机连接的客户端即可.

If you're going to have a separate server application, don't make it also display to the screen, just run another client on the server machine, connected via localhost.

这篇关于使用SFML在实时网络上验证发送的数据包的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！