cocos2d-x开发：服务端基础库封装

元旦前面几天都在忙着面试,随后的几天也就一直在作服务端基础库开发方面的工做.对于服务端开发,是好久以前的事情了.那时候我还在大学读书,一直都是在倒腾服务端开发方面的东西,毕业后参加公司工做就是一直从事客户端开发工做,再也没有碰过服务端开发的事情.刚开始我很犹豫,不过一切并无想象的那么糟糕,很快我就找回了之前的状态,整体来讲,这几天的工做成果和效率我还算是满意的.最主要的是状态回来了,因此也就不担忧其余的了.

先说一下为何我要选择本身去开发服务端的基础库.整体来讲,本身去开发服务端,从零开始,在stl和posix thread上面去开发本身的基础库是颇有难度的,会遇到不少的问题.我之因此这样子选择,是由于对于优秀源码库阅读量比较多,本身比较自信,即便遇到一些设计实现上面的问题,我也能够很快找到优秀的实现源码,第一时间去参考别人的设计实现方法.另外,和我选择开发的底层语言也是相关的,我此次并无选择使用C,也没有选择使用C/C++混编,除了底层系统级别的C库以外,我都是使用全C++方式开发的,基础的思惟方式也是面向对象.我认可,本身系统学习C++理论知识的时间还很短,但是在实际的开发过程当中,我发现已经足够支撑我前进了.惟一不足的就是,我须要作大量的傻瓜方式的测试才能保证本身写的底层模块在执行的流程上面不出现错误,固然这是在不涉及复杂业务逻辑的时候.对于须要处理复杂繁琐逻辑的地方,我都是无条件的信赖stl.在这一层面,我并无选择本身去作无畏的工做,主要仍是我相信我没有能力涉及到那个层面.

之因此选用C++去开发,而没有选择java/erlang/golang之类的语言,不是由于我真的不会这些快餐式的语言.说白了,仍是心底的执拗与偏执在做祟,其余的应该就不用多说了.其实我彻底是能够选用java/golang的,java开发起来对我来讲难度并不大,即便已经很久没有碰过,也不知道如今最新版本的JDK更新到哪里了,我想这些都不会影响个人.对于java方式的开发,我更愿意认可那是各类第三方组件的混合物,问题说到最后就只是如何快速学习和正确使用这些第三方开发组件罢了.而golang做为如今颇有竞争力的C系语言,我仍是很喜欢的,可是我怕本身还不能正确理解它的工做方式,那将直接影响我对它的使用理解.即便能作出来东西,在理解不正确的状况下,相信也拿不出手.

固然,从前面的一些文章我就开始暴露出本身好久不碰服务端开发的问题了.可是也都一一解决了.让我感到很恼火的是,我在Ubuntu Kylin上面开发,用CMake管理项目,用sublime去写代码,而sublime老是会莫名其妙的死掉,还好的是,给我形成的代码丢失每次都并非不少,也多是我喜欢疯狂保存(C-S).当make不过或者是执行test/sample发现逻辑有问题的时候就到qtcreator/kdevelop去调试.整体来讲,这个流程我渐渐的熟悉并习惯,作起事情来也算是比较的顺手,固然依靠unittest和sample,因为其简单业务逻辑的限制,我相信可能会有一些问题是发现不了的,不过这没有关系.我能够在开发后端应用的时候遇到问题,在开发中解决.

在开发以前我曾经仔细想过,并对本身作过一些简单要求.不使用隐晦难懂的语法,不依赖继承,接口设计尽可能多而简单.这些是我对本身提的要求,也是为了在设计底层接口的时候提醒本身.这几天编码下来,我都是尽可能遵循这些规则在实现方面下工夫.须要提的一点是,我受到golang的影响,在实现中不多使用继承,而是更多使用简单的组合功能.固然了,我也不是什么完美主义者,并非彻底要求本身写出彻底按照本身要求的那些代码,我仍是会使用接口方面的功能.就像是纯虚类之类的来做为接口.就像是线程执行的任务,我就直接采用了之前我使用java的那种方式,设计了一个Runnable的接口,提供一个run方法由任务子类本身去实现.这样作也是很方便的.其余的还有不少,例如,本身实现的简单的引用计数的智能指针,其中包括相似stl的std::autoptr以及boost::sharedptr这样的指针,说到实现的话,里面使用的引用计数我就是使用了gcc的原子操做作到的.细节就不说了,这方面的资料能够自行去Gnu gcc查阅官方的一手资料.网上的二手资料也不少,能够很容易找获得的.

在这几天的编码中,主要是实现了基础的一些功能,大部分的时间都花在实现锁处理,线程,线程以及线程池上面了,另外还简单的处理了一下时间,可是并无处理日期.这个延后作吧,至少我如今的需求对日期方面的处理尚未依赖.今天早上也是在着手处理网络部分的模块.因为发现本身对ip地址的格式处理根本就没有任何的经验,因此不得不暂停了网络库部分的开发,转而去了解这方面的知识,但愿今天能够补足ip格式处理方面的基础功能.另外我也考虑过了,因为我开发网络库部分是为了游戏服务端服务的,暂定的实现方式是使用reactor-aceptor的工做方式,在reactor采用epoll去管理socket io事件,对于长连接,则是提供直接建立service工做方式,基础接口我会直接给出,由上层根据业务需求本身去实现.而这部分直接实现runnable,提供独立的线程去处理r-a服务.也就是处理epoll io事件.长连接创建以后全部的任务都应该进到任务队列去,由线程池的工做线程处理.工做线程以后能够说,应该就到业务逻辑部分了.不过我不打算彻底用C++开发,因此确定会用脚本语言.至因而选用Lua仍是Python再看吧.

其实按照这种分析方式来讲,从socket管理到任务队列再到工做线程分发任务到具体服务仍是脚本,这些能够认为是与下层服务无关的,这部分既不会对通讯数据进行操做,也能够从下层服务独立出来.就是通讯调度部分.也能够说是服务端调度的核心层.接下来要考虑的事情就是,将通讯部分独立出来以后,到服务以后,服务之间的通讯问题.若是我将服务间的通讯都丢到任务队列去,由工做线程处理的话,那么须要作的就是本身独立设计一套通讯方式用来区别本地通讯和客户端到服务端请求(c2s-client to server).