4

我想创建一个基于浏览器的网络游戏。为了确保它可以被尽可能多的人使用,我想将所有流量嵌入到标准 HTTP 包中。

假设我使用 IIS 作为后端,我应该如何编写代码以最大限度地减少延迟?

从使用内存中的共享状态的某种 ASP 应用程序(可能是 ASP.NET MVC)开始是否合理?还是我应该从一开始就计划编写自己的某种 IIS 插件?还是我应该放弃 IIS 并改为编写自定义服务器?

从每个客户端重复查询开始是否合理,比如每秒十次,或者我应该以某种方式使数据更像流(如果是这样的话)?

4

3 回答 3

3

这可以正常工作,但您将不得不做一些不那么“传统”的事情。

要使这项工作正常进行,请不要执行单独的请求,保持请求打开,然后使用打开的连接传输数据。

你可以尝试使用像Bayeux这样的协议,但这里没有规则。

这是一个使用 COMET 的 ASP.NET 示例

于 2009-04-11T17:23:11.333 回答
2

设计一个每秒访问 Web 服务器 10 次的应用程序并不是一个好主意。Web 服务器设计用于较不频繁的客户端请求以及可能比您的游戏将使用的更大的处理时间和响应大小。这并不是说 Web 服务器无法应对,只是它不是有效的客户端-服务器匹配。

对于每秒需要多个数据包的任何类型的应用程序,您确实应该考虑比 HTTP 更轻的协议,后者相当冗长。例如,如果您的游戏需要发送 4 个字节来注册用户的战舰坐标,您实际上并不想传输额外的几百字节的 HTTP 标头。

我会推荐一种浏览器插件技术,比如 Flash 的 Silverlight。两者都支持 TCP 套接字连接。您需要编写自己的服务器以坐在 TCP 套接字的另一端。使用这种方法,您还可以将数据推送到客户端,而不必依赖 HTTP 所需的客户端轮询机制,例如 AJAX。

于 2009-04-11T17:20:45.690 回答
1

标准 HTTP 消息将面临的一个问题是对标头数据的大小(以及缺乏控制)。

我参与了一个有数百万人玩的 Flash 游戏的设计。我们需要每隔几秒就与服务器进行一次通信,最终使用超轻量级的 JSON 消息来节省带宽并保持其快速运行。

JSON 消息大小:16 字节

HTTP 标头大小:200+ 字节

对于高流量、低延迟的要求,HTTP 并不是一个很好的协议。它是为更大、更不频繁的请求/响应模型而设计的,并且出于这个原因具有诸如304 Not Modified 之类的状态代码。

您可能想要下拉到自定义 TCP/IP 实现。

于 2009-04-11T17:24:23.483 回答