编写网络程序应注意的几个问题060714.docVIP

编写网络程序应该注意的几个问题 刘刚 2003年9月19日星期五 2006年7月14日星期五批注 经过一年多来《天骄》网络游戏的编程工作，有了一些经验和教训，希望在这里跟大家分享。 注：后来我和我的同事编写了天骄II，增加了不少经验，在这里补上。以前我们得出的一些结论到了现在发生了变化，在这里也进行了修正和补充。毕竟我离开目标软件和网络游戏行业一年了，有些经验可以结合着具体的游戏表达出来。 网络程序与单机程序相比难度是成倍增加的 网络程序的编程和单机版相比，难度增加了许多，而且往往是超乎我们的想象的。 对稳定性需求增加 一台游戏的服务器程序需要持续不断的运行，至少要在24小时内不会发生任何问题。这与单机游戏相比，难度增加了。如果希望这款游戏的规模再大些，要求就更高了。基本上要达到电信级的水平。 注：在后来的天骄II里面，我们终于基本上做到无严重BUG，正式运营的游戏服务器可以正常运行一周没有问题，在我们自己的测试服务器上运行时间超过49天。当然这个成绩在我离开目标的时候还没有达到，还存在一个BUG不定期的会导致崩溃，这时候是去年的7月份，天骄II收费2个月。后来在去年年底，这个BUG由接替我工作的同事们找到，值得庆幸的是，导致BUG的代码并不是我们编写的，而是只作网络底层的程序员编写的。这说明我们在防止BUG方面，做得很不错。 对效率要求增加 一台服务器支持的游戏人数是非常多的，每个用户的操作也是多种多样的。中间会有慢速操作和快速操作。就需要我们分离这些操作，提高快速操作的效率，而不能让这些操作为了等一些无关紧要的东西而降低效率。对这部分内容进行优化势必会增加程序的复杂性和出现问题的可能性。 注：一般我们会用多线程来充分利用服务器上的多个CPU。 程序复杂度增加 游戏的用户操作比起那些电信的操作来说要复杂的多了。所可能导致的问题也要多很多。服务器结构的扩充，程序内部模块的划分，模块和线程之间的交互都会使得程序更加容易出现BUG，而且这些BUG更加隐蔽。 注：服务器程序的复杂度，不在于代码量的多少，而在于代码的BUG数量和优化的程度。 版本更新频繁 天骄的服务器程序从2003年2月14日至今就更新了123个版本，平均不到每两天就有一个版本。每次更新都可能包含新的BUG，新的问题。 长时间的维护，同一段代码由不同的人维护，也会增加代码中的隐患。 注：所谓的至今是只截止到我写这篇文字的时候，2003年9月，大约7个月的时间。天骄I至今还在运营，后来更新了多少版我没有统计过。 对BUG的监测 那么如何加强对如此复杂的程序的监控呢？下面有一些方法。这些方法对于单机程序而言，可能并不重要，但是对于网络程序而言，就显得比较重要了。这个时候我们写代码，其主要作用就不仅仅是实现游戏的功能，更重要的是如何使我们的代码错误更少，出了错之后更容易被找到。 注：因为网络游戏的特殊性，我们必须不断地更新游戏，所以游戏基本上不可能出现一个阶段，在这个阶段里是完全BUG Free的。很多修改都要求我们在没有完全进行测试的情况下就必须上线，实际上进行所谓的完全测试也基本上是不可能的。所以，这要求我们必须很快的定位错误，并且在错误一开始发生的时候就尽量的收到报警并找到它。 Assert 在每一个模块，线程，函数的参数输入部分，增加Assert()进行参数合法性判定。但是要注意，这个函数的作用仅仅限于Debug版，对于查找那些非常隐蔽的错误用处是不大的。所以一般仅仅在程序开发的前期使用。到了后期，基本上要以后后面的解决办法来查找问题。 assert( strlen(szMsg) sizeof(szMsg) ); 注：在天骄II的时候，因为ASSERT的作用实在是太大了，我们又增加了一个编译选项：Final版。也就是说除了普通的Debug和Release编译选项以外，又增加了一个Final。Final才是最终服务器会用到的版本。而我们在Release版里，重新定义了ASSERT()，而不是原来的简单的把代码设置为NULL。重新定义以后，ASSERT()就不再报对话框，而是直接写log文件，这在公测期间尤为重要。可以随时帮助我们防范错误。 Log文件 因为游戏的服务器经常需要长时间运行，而且大多是Release版的情况下，所以非常有必要对那些出现错误的地方进行随时的记录。对错误的输入要有记录。主要需要记录的内容有： 正常错误。程序中可能出现的正常错误，比如资源没有找到，读写磁盘失败，登陆失败等等。 非正常错误。不应该出现的错误，比如人物没有找到，道具属性没有找到，怀疑是作弊的行为等等。 对于网络程序，几乎要在任何我们认为可能出现错误的地方写下Log记录。但是因为Log记录的操作非常消耗时间，所以对于那些调用非常频繁的地方不适合用Log来记录，那