高效网游服务器实现探讨(三)
转载请注明出处:http://blog.csdn.net/phoenixsh
我又回来了。现在来讨论游戏消息的传送。在一个网游的运营成本中,带宽费用应该是很大的一块。因此如何高效编码以及收发消息就成为节省运营成本的关键。这里面能做很多文章。
首先是一个基本的判断:随着处理器的计算能力不断提高,以及多核的日益普及,在消息的编码以及收发环节,CPU资源将不会成为瓶颈。相对的,应该千方百计考虑如何在保证游戏正常运行的前提下,降低不必要的通信开销。也就是说,可以对游戏中的消息进行一些比较复杂的编码。
那么游戏中都有哪些消息?我们知道聊天和语音消息优先级比较低,而且可以通过专门的服务器来处理。真正比较关键、能够影响玩家的游戏体验的,是那些状态变更、动作、玩家之间或者玩家和服务器/NPC之间的实时交互的消息。尤其是,这些消息的传送有严格的时序要求。如果一个玩家先看到自己的角色被砍死,然后才看到对方发出来的攻击动作,甚至根本没有看到对方有什么动作,他/她肯定会愤愤不平。因此,消息系统必须保证每一条消息的及时传递,并且不能打乱它们之间的顺序。
这意味着,每一条消息必须有明确的边界。也就是说,收到一条消息之后,接收方必须能够明确这条消息有多少个字节。这是一条显而易见的要求。但是大概是出于惯性,在实践中它常常变为消息编码中的长度字段。
这无疑是一种浪费。很多消息的长度是固定的,仅仅靠检查其消息类型就可以了解其边界。变长消息的处理后面会讨论。我这里并不是说要把具体的游戏逻辑与网络代码混在一起。通过使用元数据就可以有效的把网络代码跟具体的游戏逻辑有效隔离开来。关于元数据的使用后面也会详加探讨。今天时间不多了,下面讨论消息类型的编码作为结束。
通常一个字节会被用来编码消息的类型,以方便接收方的解码。但是我们知道,游戏中并不是每种类型的消息的传送频率都是一样的。事实上,我们知道哪些消息会被大量发送,哪些消息的频率会低很多,而另外一些消息,一天也不会有几条。明乎此,就可以采用非对称的编码方式来编码消息的类型。这就是Huffman编码。对于占据了绝大部分通信量的状态变更消息而言,即使每条消息节省下半个字节,也是非常划算的。以我的经验,一台普通PC可以作为服务器支持2000人同时在线的实时动作类游戏,消息通量是每秒10000条;如果一个服务集群有5台处理器,那么就相当于节省了200kbps的带宽。这还仅仅是从消息类型编码方面榨取的。当然,Huffman编码的解码是比较麻烦的,效率也会低一些。但是正如前面所指出的,这部分的运行开销并不会造成性能瓶颈。
(由于本人已经离开网游行业,这里的讨论将会比较粗略,更不可能给出代码。各位朋友如有疑问,请直接留言。我会尽量答复。今天到此结束。后续章节请耐心等候。)
发表于 @
2007年10月28日 22:10:00 | | 编辑|
举报| 收藏