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

《编写网络程序应该注意的几个问题060714》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、编写网络程序应该注意的几个问题刘刚2003年9月19日星期五2006年7月14日星期五批注经过一年多来《天骄》网络游戏的编程工作，有了一些经验和教训，希望在这里跟大家分享。注：后来我和我的同事编写了天骄II，增加了不少经验，在这里补上。以前我们得出的一些结论到了现在发生了变化，在这里也进行了修正和补充。毕竟我离开目标软件和网络游戏行业一年了，有些经验可以结合着具体的游戏表达出来。网络程序与单机程序相比难度是成倍增加的网络程序的编程和单机版相比，难度增加了许多，而且往往是超乎我们的想象的。对稳定性需求增加一台游戏的服务器程序需要持续不断的运行，至少要在

2、24小时内不会发生任何问题。这与单机游戏相比，难度增加了。如果希望这款游戏的规模再大些，要求就更高了。基本上要达到电信级的水平。注：在后来的天骄II里面，我们终于基本上做到无严重BUG，正式运营的游戏服务器可以正常运行一周没有问题，在我们自己的测试服务器上运行时间超过49天。当然这个成绩在我离开目标的时候还没有达到，还存在一个BUG不定期的会导致崩溃，这时候是去年的7月份，天骄II收费2个月。后来在去年年底，这个BUG由接替我工作的同事们找到，值得庆幸的是，导致BUG的代码并不是我们编写的，而是只作网络底层的程序员编写的。这说明我们在防止BUG方面，

3、做得很不错。对效率要求增加一台服务器支持的游戏人数是非常多的，每个用户的操作也是多种多样的。中间会有慢速操作和快速操作。就需要我们分离这些操作，提高快速操作的效率，而不能让这些操作为了等一些无关紧要的东西而降低效率。对这部分内容进行优化势必会增加程序的复杂性和出现问题的可能性。注：一般我们会用多线程来充分利用服务器上的多个CPU。程序复杂度增加游戏的用户操作比起那些电信的操作来说要复杂的多了。所可能导致的问题也要多很多。服务器结构的扩充，程序内部模块的划分，模块和线程之间的交互都会使得程序更加容易出现BUG，而且这些BUG更加隐蔽。注：服务器程序的复

4、杂度，不在于代码量的多少，而在于代码的BUG数量和优化的程度。版本更新频繁天骄的服务器程序从2003年2月14日至今就更新了123个版本，平均不到每两天就有一个版本。每次更新都可能包含新的BUG，新的问题。长时间的维护，同一段代码由不同的人维护，也会增加代码中的隐患。注：所谓的至今是只截止到我写这篇文字的时候，2003年9月，大约7个月的时间。天骄I至今还在运营，后来更新了多少版我没有统计过。对BUG的监测那么如何加强对如此复杂的程序的监控呢？下面有一些方法。这些方法对于单机程序而言，可能并不重要，但是对于网络程序而言，就显得比较重要了。这个时候我们

5、写代码，其主要作用就不仅仅是实现游戏的功能，更重要的是如何使我们的代码错误更少，出了错之后更容易被找到。注：因为网络游戏的特殊性，我们必须不断地更新游戏，所以游戏基本上不可能出现一个阶段，在这个阶段里是完全BUGFree的。很多修改都要求我们在没有完全进行测试的情况下就必须上线，实际上进行所谓的完全测试也基本上是不可能的。所以，这要求我们必须很快的定位错误，并且在错误一开始发生的时候就尽量的收到报警并找到它。Assert在每一个模块，线程，函数的参数输入部分，增加Assert()进行参数合法性判定。但是要注意，这个函数的作用仅仅限于Debug版，对于

6、查找那些非常隐蔽的错误用处是不大的。所以一般仅仅在程序开发的前期使用。到了后期，基本上要以后后面的解决办法来查找问题。assert(strlen(szMsg)

7、接写log文件，这在公测期间尤为重要。可以随时帮助我们防范错误。Log文件因为游戏的服务器经常需要长时间运行，而且大多是Release版的情况下，所以非常有必要对那些出现错误的地方进行随时的记录。对错误的输入要有记录。主要需要记录的内容有：l正常错误。程序中可能出现的正常错误，比如资源没有找到，读写磁盘失败，登陆失败等等。l非正常错误。不应该出现的错误，比如人物没有找到，道具属性没有找到，怀疑是作弊的行为等等。对于网络程序，几乎要在任何我们认为可能出现错误的地方写下Log记录。但是因为Log记录的操作非常消耗时间，所以对于那些调用非常频繁的地方不适合

8、用Log来记录，那就需要下面的方法。WriteLogFile("easyrpg.log","Herecann