HTTP 作为游戏的通信层
我刚刚开始涉足一些游戏开发，想创建一个简单的多人游戏。使用 HTTP 作为多人游戏的主要通信协议是否可行。 我的游戏不会每秒发出多个请求，而是每隔几秒发出一个请求。客户端将是移动设备。
我问的原因是，我认为尝试使用 Tornado 可能会很有趣，据报道，Tornado 具有良好的扩展性，支持非阻塞请求，并且可以处理“数千个并发用户”。
所以我的客户端可以发出一个 HTTP 请求，当游戏服务器有信息告诉它时，它就会响应该请求。我相信这说明了一些人所说的 COMET 设计模式。
我知道在套接字级别工作的开销较少，但我只是想知道考虑到我的游戏要求这是否可行？或者我只是想疯了？
提前致谢。
I've just started dabbling in some game development and wanted to create a simple multiplayer game. Is it feasible to use HTTP as the primary communication protocol for a multiplayer Game.
My game will not be making several requests a second but rather a a request every few seconds. The client will be a mobile device.
The reason I'm asking is, I thought it may be interesting to try using Tornado which reportedly scales well and supports non blocking requests and can handle "thousands of concurrent users".
So my client could make a HTTP Request, and when the game server has somethign to tell it, it will respond to the request. I believe this illustrates what some people call the COMET design pattern.
I understand that working at the socket level has less overhead but I am just wondering if this would be feasible at all given my game requirements? Or am I just thinking crazy?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
问：使用 HTTP 作为多人游戏的主要通信协议是否可行？
答：使用 HTTP 作为通信协议可能对您的游戏有意义，也可能没有，但这由您决定。我为 Windows Mobile、Blackberry、Android 和 iPhone 开发应用程序已有 10 多年的时间。一直回到CE 1.0。考虑到这一点，这是我的观点。
首先，我建议按照 Teddy 的建议阅读 RFC 3205。它详细解释了我的建议的原因。
一般来说，HTTP 很好，因为...
HTTP 可能不好，因为...
例如，Omegle.com 发送 420 字节的标头数据来发送 9 字节的有效负载。
如果你正在编写服务器和客户端，那么我会直接使用 TCP。如果您已经了解 python，那么请使用twisted 网络库。只需按照教程进行操作，您就可以在一个小时左右的时间内搭建一个简单的服务器。
查看 LineReceiver 示例，了解一个超级简单的服务器，您可以使用任何 telnet 客户端进行测试。
http://twistedmatrix.com/projects/核心/文档/howto/servers.html
Q: Is it feasible to use HTTP as the primary communication protocol for a multiplayer Game.
A. Using HTTP as a communication protocol may make sense for your game, probably not, but that's for you to decide. I have developed applications for Windows Mobile, Blackberry, Android and iPhone for just over 10 years. All the way back to CE 1.0. With that in mind, here is my opinion.
First I suggest reading RFC 3205 as Teddy suggested. It explains the reasons for my suggestions in detail.
In general HTTP is good because...
HTTP may be bad because...
For example Omegle.com sends 420 bytes of header data to send a 9 byte payload.
If you're writing the server AND the client, then I would go straight to TCP. If you already know python then use the twisted networking library. You can get a simple server up in an hour or so just following the tutorials.
Check out the LineReceiver example for a super simple server you can test with any telnet client.
http://twistedmatrix.com/projects/core/documentation/howto/servers.html
WRT：
“我的客户端可以发出 HTTP 请求，当游戏服务器有信息告诉它时，它就会响应该请求。”
这不是 HTTP 应该的工作方式。所以，不，HTTP 在这里不是一个好的选择。如果超时后未收到响应，则 HTTP 请求超时（60 秒是常见的默认值，但具体取决于具体情况）。
WRT:
"my client could make a HTTP Request, and when the game server has somethign to tell it, it will respond to the request."
This is not how HTTP is supposed to work. So, no, HTTP would not be a good choice here. HTTP requests timeout if the response is not received back with the timeout (60 seconds is a common default but it would depend on the specifics).
请阅读 RFC 3205：关于使用 HTTP 作为底层，它涉及这个问题。
Please read RFC 3205: On the use of HTTP as a Substrate, which deals with this.
由于目标平台是移动设备（以及由此带来的有限带宽），HTTP 不会是我开箱即用的第一个工具。
With the target platform being a mobile device (and the limited bandwidth that entails) HTTP wouldn't be the first tool I would pull out of the box.
如果您只是喜欢使用所有这些技术，那么您可以尝试一下。如果可以参考网站上的示例，Tornado 似乎是一个合理的选择。但是任何简单的服务器端网络语言都足以以您提到的速度提供您所需的响应。性能特征在这里可能是无关紧要的。
COMET 方法是指长时间保持 HTTP 连接打开的情况。它主要用于数据的“服务器推送”。但通常你不需要这个。发出重复的请求并单独处理响应通常要简单得多。
If you just fancy playing with all this technology, then you could give it a go. Tornado seems like a reasonable choice, if the example on the web site is anything to go by. But any simple server-side web language would suffice for serving up the responses you need at the rate you have mentioned. The performance characteristics are likely to be irrelevant here.
The COMET method is when you leave a HTTP connection open over a long period. It is primarily there for 'server push' of data. But usually you don't need this. It's usually much more straightforward to make repeated requests and handle the responses individually.