Twisted Spread 适合多人赛车模拟游戏吗？
您认为 Twisted Spread 是否适合（就性能而言）多人赛车模拟器？该应用程序的其余部分基于 Python-Ogre。
Perspective Broker 能否在（可靠？）UDP 上运行？
Do you think that Twisted Spread may be suitable (in terms of performance) for a multiplayer racing simulator? The rest of the application is based on Python-Ogre.
Can Perspective Broker run upon (reliable?) UDP?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
几乎可以肯定，这是一个合理的协议。请记住优化的基本规则：不要这样做。使用任何基于 TCP 的协议都比使用任何基于 UDP 的协议要容易得多。对于项目的成功来说，这最初比在客户端和服务器之间发送消息是否需要 30 毫秒或 45 毫秒重要得多。最终，当您明确您的项目实际上可能会成功并且您确实需要弥补这 15（或任意多）毫秒时，您可以重新访问网络层并考虑是否存在性能瓶颈（无论是延迟）或其他一些指标）取决于您选择的协议。如果是这样，那就是花时间评估各种替代方案的时候了。只有到那时，选择理想协议的努力可能会得到回报（因为您距离完成的项目更近了），到那时您将对问题有显着的理解，并且应该非常具体地确定您的要求，另外两件事将使选择适当协议（无论是基于 TCP 还是基于 UDP）的任务变得更加容易并且更有可能是正确的。
It's almost certainly a reasonable protocol to start with. Remember the cardinal rule of optimization: don't do it. Working with any TCP-based protocol is going to be considerably easier than working with any UDP-based protocol. This is initially much more important to the success of your project than whether it takes 30 milliseconds or 45 milliseconds to send a message between your client and server. Eventually, when you've gotten to the point where it's clear your project might actually succeed and you really need to make up those 15 (or however many) milliseconds, you can revisit the network layer and consider whether the performance bottleneck (be it latency or some other metric) is due to your choice of protocol. If so, that is the time to spend time evaluating various alternatives. It's only at that point that the effort of selecting the ideal protocol might pay off (since you're that much closer to a completed project) and by then you will have a significantly improved understanding of the problem and should have nailed down your requirements very specifically, two more things which will make the task of selecting the appropriate protocol (be it TCP- or UDP-based) that much easier and more likely to be correct.
对于你的第一个问题，是的，PB 的性能对于实时游戏来说已经完全足够了。一些游戏是用PB编写的。例如，MV3D 使用 Twisted 和 Python-OGRE 来呈现共享的物理模拟。
对于第二个问题，PB 运行在面向流的传输上。它可以使用诸如 PTCP 随顶点一起提供的模块。
但是，您应该意识到“可靠的 UDP”通常性能比普通的旧 TCP 差得多。整个互联网上的路由器都了解 TCP，并可以利用这种理解来优化它。如果您在 UDP 之上实现可靠性，那么您必然需要实现功能上与 TCP 等效的东西，然后有几个因素会对您不利：
在某些情况下，可以使 UDP“更快”的是放弃 TCP 所做的大部分工作，因为不可靠 。如果您的消息传递层不可靠，那么您必须知道它传递的数据可能会被任意丢弃。
通常，游戏中适合通过 UDP 传输的数据是运动数据。当你的位置发生变化时，你可以发送一个 UDP 数据包，它可以被丢弃，因为游戏只关心你最近的位置 - 一旦收到更新，所有以前的位置都无关紧要。许多游戏通过一个（不可靠的）UDP 通道发送运动数据，然后通过更可靠的 TCP 通道发送所有控制消息。
但是，Jean-Paul 关于优化的回答很好地表明了您何时可能需要考虑实施该优化。
To your first question, yes, PB's performance can be perfectly adequate for a real-time game. Several games have been written using PB. For example, MV3D uses Twisted and Python-OGRE to present a shared physical simulation.
To your second question, PB runs upon a stream-oriented transport. It could run on top of "reliable UDP" using something like the PTCP module that comes along with vertex.
However, you should be aware that "reliable UDP" will generally perform much worse than plain old TCP. Routers all along the internet understand TCP and can optimize it by using that understanding. If you implement reliability on top of UDP, by necessity you will need to implement something functionally equivalent to TCP, and then several factors will penalize you:
What can make UDP "faster" in some circumstances is discarding much of the work that TCP does, by being unreliable. If your messaging layer is unreliable, then you have to know that the data it's delivering can be arbitrarily discarded.
Usually, the data that's suitable for transmission over UDP within a game is movement data. When your position changes, you can send a UDP packet and it can be discarded because the game only cares about your most recent position - once an update has been received, all previous positions are irrelevant. So many games send movement data over one (unreliable) UDP channel, then all control messages over a more reliable TCP channel.
But, Jean-Paul's answer about optimization is a good indication of when you might want to consider implementing that optimization.