工作之外的学习/开发计划(1) -- windows/linux服务器程序支持库的开发

工作之外的学习/开发计划(1) -- windows/linux服务器程序支持库的开发

write by 九天雁翎(JTianLing) -- blog.youkuaiyun.com/vagrxie

讨论新闻组及文件

五个月以前的计划。。。。。。。现在修补了一下。最近真的是开始学习网络了，慢慢来吧。

目标：

简化服务器程序的开发，设计合理的服务器框架程序。 --- 主要目的

实现工程文件（对我来说一般就是服务器程序）以同一套源码在windows和linux下的编译运行。 -- 次要目的，但是必完成-_-!

其实对于支持库来说，很重要的一点来说，就是尽量对外实现操作系统无关的同一套接口。。。。

顺面把我的测试环境及开发环境说一下:

windows XP VS2005 VA vimemu boost 1.36

ubuntu 8.04 gcc version 4.2.4 vim+gdb boost 1.36

源代码控制统一在ubuntu8.04中用用svn.

另外:

其他工具包括.IBM Rational Rose Realtime(又是习惯问题,虽然不是Realtime的程序,但是因为公司用的是这个,个人沿用此习惯)

对了,其实我很有可能中途将VS2005换到VS2008,因为我很喜欢2008的特性包:)那样可以尝试用用MS的TR1,-_-!但是…..linux下没有VS2008SP1可用faint….废话………所以，此程序中即使用到boost(可能很多时候是为了省事，也会尽量抽取代码，自我设置一套，而不是沿用原有的boost,以防版本问题-_-!作为开源软件，很多东西的版本兼容都是不那么在乎的，包括gcc都是这样，所以还是自己控制的好。

首先分析好处：好处的明显大家应该都能看到，尽量减少移植的成本。对于公司来讲，这样的好处显而易见。对于我个人来讲，呵呵，两边都能学到东西o(∩_∩)o…

其次，就我感觉，对于我们公司，有个好处是很明显的，虽然我们很需要linux的服务器，但是真的能在linux下做开发的人太少。。。。。所以，有了这么一套库，大家都使用共同的VS2005做开发，调试，测试，运行完毕后，再移植到linux下去。弥补（或者说掩盖）了开发人员不熟悉linux下开发环境的问题。这点其实也很重要，不然的话，公司得请一堆熟悉linux开发的人来做程序，成本肯定比windows程序员高啦（个人感觉，还不说难不难找的问题）。

另外，一套程序可以同时在windows下，linux下运行（跨平台？），这样公司的服务器配置可以更加灵活，更加可以按需配置。不过说实话，其实很多时候配置linux仅仅是为了省钱，linux下配合用mysql的话那就更加省钱了，知道SQLServer,Oracle这些东西多少钱一套吗？-_-!。。。。当然，也许还有安全。

坏处：其实也可以看到，开发一个这样的程序，开发成本提高了。。。。。。为了跨平台而导致了很多操作系统特性的东西不能使用，这样很多时候增加了代码复杂度，有的时候其实还牺牲了性能，限制了思维。

其次，源代码的维护的确要比单一操作系统的代码难以维护，因为难以避免的需要用到该死的宏。。。。。。。。。。。。当然，宏真死了我们还真没有合适的替代工具。。。。。。。

需求列表：（仅仅是知识还非常欠缺的我目前能想到的，以后需要再添加吧）

网络框架支持：

windows服务器TCP用IOCP模型

linux服务器TCP用epoll模型

UDP都用同一套

另外，为简单的网络应用程序（其实在我们公司中是客户端跑的）使用select模型。（就目前我浅显的网络知识了解，我不明白为什么要这样，select其实也是属于I/O复用的模型了，但是实际客户端方面用的都是单套接字，单连接，单处理线程，难道仅仅是为了防止输入阻塞和套接字API阻塞的冲突？）

服务器其他支持库

1. 序列化支持。

2. 日志系统支持。

3. 脚本语言配置文件支持。（可考虑上脚本系统）

4. 运行时异常dump支持。

5. 多线程支持。（其实看很多书说Linux下弄单进程更好，但是那样和windows下共用一套源码估计就更难了。）

6. windows下也能跑的posix库。

7. ODBC库/mySQL API 支持库(任选)

8. 多进程支持（待选）。

也许还需要加上前篇，可移植UNICODE支持库。这里还有个UTF8和UNICODE的抉择问题，我在windows下开发相对还是比较多，更熟悉的当然是UNICODE,但是目前linux下面默认的UNICODE已经是新标准的4字节了，这样就算同样的接口，可能也不一定和windows的兼容，要用同一套代码可能还得设置unicode-short的编译选项，这样个人感觉也不是什么长久之记，其实还不如用UTF8方便，用UTF8的坏处很明显，那就是处理的函数少一些，而且，字符的长度不一，不如UNICODE好处理。

简要分析：

对于网络框架就不多说了，基本上应该是目前大家比较认可的网络模型，不然我们公司也不会用。

支持库：

1. 序列化：

这是我来公司上的第一课。。。。。。。。为什么要序列化？现在我还大概记得，实现操作系统，硬件平台无关的数据保存和传输。

简而言之，解决诸如大头，小头等问题。目前我自己的感受还有，对于保存数据和读取数据使用同一套接口，简化了数据管理的结构，方便使用。

在网络传输中打包，解包，数据结构的保存读取中序列化都是必不可少。

对了，这里复述一下总监的话：“其实MFC的序列化类就足够用了，但是Linux下没有MFC。”o(∩_∩)o…

2. 日志系统：

日志系统对于服务器来说有多么需要，这里也复述总监的一句话（-_-!不会找我要版权费吧，这里感谢总监一直以来的教导。。。。）

“服务器的开发相对于客户端的而言更加枯燥，因为你没有办法亲自的感受自己的工作成果，并及时的看到改变（要知道，我们开发的可是游戏，客户端就是游戏啊。。。。。。），开发完成后能看到的也就是黑底白字的一行行记录。但是，其实是各有各的乐趣。”

呵呵,总监这里所谓的一行行记录,就是输出到命令行屏幕上的日志啦:)当然,日志还需要写入文件的.

日志对于服务器开发人员来说就是眼睛一样重要的东西.服务器运行状况,错误分析等等很多时候就是靠日志来完成的.这里想再提一下,总监曾说他不喜欢gdb的调试……在linux下服务器的debug主要就靠日志来完成…………-_-!

呵呵,这里仅仅是想说说日志的重要,不是告诉大家都这样做啊……….

顺面提几点需求,需要日志能输出到屏幕,写入文件,可以按启动时间记录新日志,不覆盖原有日志,能分级处理……

3. 脚本语言配置文件支持:

配置文件是很多程序都需要的,不仅仅是服务器的支持库而已:).服务器很多东西都可以通过配置文件来完成.诸如服务器ID,version,IP,Port,等等,等等.

想想VIM的配置文件吧……………..汗一个,强大到无与伦比.

那就是我的目标,不过我没有办法像vim一样实现一个新的script语言(是新的吗?),

其实VIM的配置文件还支持python…………….再汗一个…..

目前我的想法是,提供一组接口,我自己实现lua,python(我懂的两个脚本语言)的支持.假如有其他需要,以后再去实现别的东西就好了.

用脚本语言来写配置文件的好处也提一点,更好的错误控制和更灵活的功能.

4. 运行时异常dump支持:

有的时候光靠日志很难知道以前的错误在哪,这时候就需要dump了,o(∩_∩)o…,在公司我开发的第一个东西就是关于这个系统的:)当时研究google的breakpad很久,收获不少.

5. 多线程库支持:

服务器程序有单线程的吗?我不知道,但是起码我知道,多线程的服务器好像比较普遍…..呵呵,那么这个库就必不可少了,因为多线程不是C/C++语言的内建支持功能,linux下和windows下根本不一样,无论是从创建新线程,线程间通信的方式都不一样….我现在都还不知道,我能不能完成这样一个库-_-!

真希望当时BS能有别的想法,为c++内建多线程的支持,或者在标准库中提供多线程的支持….再或者,提供一组参考的接口,怎么都好….我就不需要做这样的工作了…呵呵

PS.多线程的问题是服务器运行错误的主要问题……………………..

6. posix库:

对于这样的跨平台程序,最合适的想法就是只用ANSI C及其库…..就像lua的实现一样.再不成就只用C++及其标准库.

但是编程没有那么简单…你很多时候需要超出这些语言范畴的系统功能,这个时候,他们不能帮你…..再退一步….用posix库

我没有自己完成实现这个库的意思,这里提出来是因为linux下用这个库很正常(那不就是那些家伙定的标准吗?),但是,windows下其实也有对posix库的支持(不知道完不完整,就我使用而言,需要的都有了).但是在函数命名上windows喜欢在函数前面加下划线,有的时候甚至是库的名字都有出入.这时候就需要更多额外的工作了……常常就是一堆的宏替换….faint!还是宏,该死的宏.

另外,其实就我实际工作中的感受,对于很多宽字符的处理函数C或C++标准库中都没有提供,都是MS自己加的,这时候就也需要自己辨别了,或者,就像我们公司那样做,自己去实现你需要的函数……然后加入库中…….对于此库的开发方式,我准备使用和目前公司使用的一样的模式,insert when you need.

7. ODBC库/mySQL API 支持库(任选):

服务器程序经常性的需要用到数据库……….我也不知道为什么,他们叫服务器,不就是为客户端服务的吗?这个服务,常常需要记录数据,当数据量很大的时候,就需要数据库了……..

晕……………..参看数据库发展史……………………

ODBC库是因为较为通用,SQL Server,mySQL等数据库都可以使用(我目前还没有用过Oracle.

但是,就我自己使用而言,mySQL就足够了,那么用mySQL API也不失为一个好办法,因为,少了一个中间层,对于mySQL而言会更快.

提出这个问题,也不是说我要去开发ODBC库和mySQL API…….还需要我去开发吗?-_-!

仅仅是说明,为了更方便使用,我会对需要的接口再做一层包装.也许是为了做连接池增加数据处理效率等等工作.

8. 多进程支持:

我不知道这个需求强不强烈,实际中倒是碰到过一次.CreateProcess的方式和Fork&Exec的方式我不知道哪个效率更高,但是创建方式上其实还比较容易做到统一,在公司我也是通过都是用进程id做了一套。问题是通信….o(∩_∩)o…,还好总监告诉我了一个好办法……………套接字………….但是，假如有别的需要，可能还得弄别的方式。

write by 九天雁翎(JTianLing) -- blog.youkuaiyun.com/vagrxie