如何设计游戏服务器的通信通道

Posted 2023-03-07

【中文标题】如何设计游戏服务器的通信通道

【英文标题】：how to design a communicate channel of game server

【发布时间】：2011-05-25 08:52:24

【问题描述】：

我打算设计一个游戏服务器。我希望它可以承受非常重的负载，可重用，灵活，但易于编程，我想平衡这些点。

我决定用nodejs和redis，protocal的数据格式是json，websocket

我有web开发经验，但对游戏服务器开发没有概念，我注意到游戏服务器非常实时，消息不是点对点，而是发布-订阅通道，

nodejs、redis、JSON 是否是设计通信通道的好选择，大多数浏览器都支持 websocket 吗？

可能问题太多了，唯一的问题就是？

【参考方案1】：

您似乎对很多事情的概括不足。当然有游戏协议是点对点的，这完全取决于游戏的设计，是否使用中心化服务器。

此外，许多游戏使用二进制协议，比特流很常见以节省带宽。 JSON 至少比那个世界好几个数量级，所以也许你应该将你的范围从“游戏”限制到更有限的东西。在这里，您似乎过于概括了。

【讨论】：

我想开发一个快速的网页游戏，所以我选择了 JSON，我认为压缩后的 JSON 类似于二进制，对吧？

嗯，这当然很有帮助。既然你已经对他们进行了足够的取笑，也许你可以指出逻辑上的缺陷？毕竟，这是一个问答网站。

【参考方案2】：

最终用户 PC 上的大多数浏览器都不支持 Websocket。尝试通过 HTTPS 使用无限加载 iframe（通过 SSL 以避免愚蠢的代理在传递之前完全加载无限加载 iframe）来接收数据，这得到了广泛支持。对于发送，请使用 AJAX 请求。

使 iframe 页面推送线像这样通过 http:

<script>newData("...")</script>

如果这对您来说太慢，请使用进行通信的 flash/java 小程序。

【讨论】：

很棒，类似于 JSONP，但更实时

无限加载页面是否可以被 nginx 压缩？

【参考方案3】：

首先，下次使用真正的node.js 标签，这样人们才会真正找到你的问题。

关于实际问题，是的，Node.js 非常适合多人游戏，尤其是 WebSockets ......但由于最近发现代理服务器配置错误的安全问题（实际上是不是 WebSocket 的错，但每个人和他们的妈妈都对此感到恐慌）。

详情：http://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/http://blog.pusherapp.com/2010/12/9/it-s-not-websockets-it-s-your-broken-proxy

与此同时……

如果您想要延迟小于 100 毫秒的游戏，则可以使用 Flash Sockets 作为后备。

另外，JSON 是 一个坏主意。发送游戏数据非常臃肿，当我使用 Node.js 创建我的第一个多人游戏时，我所做的是创建 BiSON。这就像 JSON 的替代品一样，它不支持 100% 的 JSON 功能，但它致力于小尺寸的编码数据和速度。

因此，如果您愿意尝试使用 WebSockets 或在不久的将来使用 Flash 套接字，那么您应该看看我制作的两个游戏：

https://github.com/BonsaiDen/NodeGame-Orbit（战略游戏 á la Eufloria）https://github.com/BonsaiDen/NodeGame-Shooter（小行星/几何战争多重交叉）

但请记住，根据您的游戏类型，您需要的不仅仅是发送消息，尤其是如果您想获得延迟补偿等。

【讨论】：

这两个游戏使用了哪个版本的node.js。 BiSON 可以支持 java 吗？

@guilin 2.x 用于 Shooter，3.x 用于 Orbit。 Java 支持，必须自己为 Java 编写一个 BiSON 版本。

当我查看你的 orbit/server/lib/socket.js 代码时，我还有一个问题——fluffsocket 是什么？

@guilin 这只是我为我的其他项目之一做的一个简单协议（它使用 Googles V8 作为游戏引擎），最初我想将 Orbit 移植到那个东西上，而且更容易编写我自己的协议，然后在 C++/JS 中实现 WebSockets。

您的意思是 2 个不同的协议共享 1 个服务器套接字。我不明白为什么 WebSocket 和 FluffSocket 的读/写方法如此不同？为什么 \x00 \xff 环绕数据？

【参考方案4】：

对于通信渠道，我推荐socket.io，它在浏览器支持的任何内容之上提供了一个类似于 websockets 的 API。它回退到 Flash 套接字，然后根据需要使用 jsonp 和长轮询。它在 Node 中得到了很好的支持，而且随着用户的浏览器原生支持 websocket，事情会自动变得更好。

您可以在不到 100 毫秒的时间内完成 http 请求——在家里，我经常看到大约 75 毫秒从 Google AJAX API 服务器获取 25K 的 jquery.min.js，大约 25 毫秒返回未修改的内容——但这需要小心工程是肯定的。如果你有一个 keepalive 连接，那么你就没有连接设置开销（如果你正在使用 SSL 来保护用户凭据，这一点尤其重要），因此它可以变得更快。

即便如此，我还是会使用 socket.io，因为它也提供了很好的 API。