c++

我的编程语言经历

Alan Perlis 说过:“一种不改变你编程的思维方式的语言,不值得去学。”,虽然写了这么多年程序,用了这么多的语言,但我自认还没悟道编程语言如何改变我的思维方式。

几天前,我需要用python来为ledisdb写一个客户端,我突然发现,对于c++,go这种语言,我如果需要实现一个功能,首先想到的是问题是代码应该怎么写。但是当我使用python的时候,我首先考虑的问题是在哪里去找一个库用来解决我的问题。可能这就是使用不同语言带给我的不同思考方式吧。

我的编程语言经历没有那么复杂,没用过很多,但是其实也够我受的了,尤其是在不同语言语法糖之间切换的时候,有种让人崩溃的感觉。没准我应该升级一下我的大脑cpu,使其能够更快速的进行中断处理。

c

我是从大学才开始学习编程的,相比现在的小朋友来说,可以叫做输在了起跑线上面。谁叫以前生活在山区,没机会接触电脑这玩意。

我的第一门编程语言是c,不同于很多童鞋使用的谭浩强神书,我用的是周纯杰的<>,不知道每年有多少同学受到过它的摧残,当然还有那哥们蹩脚的普通话。

在大学里面,很多同学的c的毕业设计都是我帮其完成,但我始终觉得自己仍然是个半吊子,除了c的基础稍微强一点之外,很多方面譬如操作系统,算法等完全不会。(现在随着工作年限的增加让我越发后悔,当初怎么就不稍微学点这些知识,尤其是编译原理。)

我几乎没怎么用c开发过项目,只在tencent可怜的维护过别人的c项目,但至少能看懂c代码,这就够了。

因为大多数时候,我用的是c++,而不是c来解决我的问题。

c++

c++是我工作使用的第一门语言,也是我使用时间最长的一门语言,都七年之痒了,不过还是有点不离不弃的。

以前上学的时候有一句口头禅,叫学好c++,走遍天下都不怕。但是有几个人能把它学好的?所以千万别说自己精通c++,那会被人鄙视的。

我使用c++可以分为三个阶段:

类c阶段

这个阶段主要是我第一份工作的时候,那时候才毕业,c的烙印很深,面向对象除了有个概念,真正是啥完全不知道。所以最喜欢的方式还是写着一堆函数来解决问题,当初VIA身边那帮c++的牛人竟然能忍受我这样的代码,真佩服他们。

面向对象阶段

后来去了第二家公司linekong,开始做游戏,才开始真正意义上的用c++写代码了。

记得最开始去第一家公司面试的时候,被问了啥是面向对象,当时不假思索的答了继承,多态和封装。

啥叫封装?整一个class,把该包的都包了,一个同事曾告诉我,他见过有几万行代码的class,看来我这个几千行的太小儿科了。

啥叫继承?先来一个父类,干脆叫bird,有一个fly方法,再来一个子类,叫duck吧,继承了bird,不过duck会fly吗?一个父类不够,再来一个,搞个多重继承,什么?出现了菱形继承,那干脆在来一个virtual继承得了。

啥叫多态?不就是virtual function,然后父类指针能在运行时根据实际情况调用相应的子类实现。那c++的多态是怎么实现的?看看<<深度探索c++对象模型>>不就行了。

这段时间,可以算是我写c++代码最多的时候,都快写到吐了,尤其还要忍受那龟速的编译。我们竟然都实现了直接通过汇编改c++的虚表,使其调用自己的函数这种变态的东西。在那时候我就得出结论,如果不想早死,尽量别用这个东西写代码。可是到如今我都在不停的慢性自杀。

现代C++阶段

不知道从什么时候开始,我突然觉得我应该来点modern c++的编写方式了,c++0x都出了,还不玩一下就晚了。当然新特性那么多,不可能全部都拿来用的,Bjarne Stroustrup貌似都说过,c++0x应该算是另一门语言了。

于是哥就走上了伪modern c++之路,class还是需要的,不然数据怎么封装。继承吗,比重减轻吧,最好采用面向接口的编程方式。而多态,能不用就不用吧,反而觉得bing + function的方式实现的delegate模型反而更方便,没准也更酷哟。

shared_ptr,weak_ptr是需要用的了,c++没有gc,所以一套好的内存管理方式是必不可少的,每次new之后还要记得delete也比较烦,最严重的是可能忘记那就内存泄露了。

于是,我就自认为我进化了,最典型的例子就是我写的高性能网络库libtnet,感觉很modern了。

lua

最开始知道lua,是云风那本编程感悟的书,当时可是菊花一紧,觉得这东西是啥,为什么能跟c结合到一起使用?

后来自己开发游戏了,才发现lua真的是一门很强大的语言,短小精悍,嵌入简单,性能超强,完全是作为游戏脚本语言开发的不二人选。不过我最开始使用lua的经历不怎么happy,最开始就是接手了一个c++与lua的粘合层库,关于这个库的传说,见这里Lua 不是 C++。后来,在踩了无数个坑,填了无数个坑之后,我终于弄得相对稳定了。貌似现在我以前的同事还在使用,不过正如我在lua c函数注册器中说明的那样,对于语言的交互,简单一点才好。现在以前做的游戏已经开源,见这里,那个传说中的蛋疼粘合层也见了世面。当然,我可不会告诉你们好多搓代码是我写的。

后来,在现在的公司,因为项目的需要,我们急需解决python的很多性能大坑问题,于是我开始推广使用openresty,一个用lua包裹的nginx,用了之后,腰不痛了,腿不痛了,性能妥妥的。

因为lua,我第一次尝到了在代码里面直接写配置的便捷,用一个table搞定,相比起来,c++处理ini,json这些的弱爆了。另外,动态语言的热更新机制使其代码升级异常方便,不过你得非常小心lua的闭包,没准你重新加载了代码运行还是老样子。

lua是一个动态语言,所以不用我们管内存释放问题,但是仍然可能会有引用泄露,在开发游戏的时候,为了解决我们程序lua内存泄露的问题,我曾经干过直接从_G递归遍历,扫描整个lua数据的事情。相比在c++使用valgrind这些程序的工具,lua配套的东西还是太小儿科了。

lua的调试也是一个大头问题,我曾今写过几个lua的调试器,例如这个,甚至都支持了类似gdb那样ctrl+c之后动态的设置断点,可是仍然没觉得比gdb方便,所以多数时候,我都是写log为主。

python

虽然小时候吃过很多蛇,但是蟒蛇可是从来没吃过的,现在看来python味道还不错。

我是来了kingsoft之后才开始正式使用python的。对于为啥使用python,我曾跟拉我进来的技术老大讨论过,他直接就说,开发快速,上手容易。

python开发的快速很大程度是建立在丰富的第三方库上面的,我们也使用了很多库,譬如tornado,gevent,django等,但是正如我最开始说的,因为我们有太多的选择,面对一个问题的时候,往往考虑的是如何选择一个库,而不是自己如何实现,这其实在某种程度上面使得很多童鞋知其然而不知其所以然。这点,lua可能是另一个极端,lua的定位在于嵌入式和高性能,所以自然地,你得自己动手造轮子(当然,现在也有很多好的第三方库了),虽然有时候写起来很不方便,但是至少自己很清楚程序怎么跑的。

当然,我绝对没有贬低python的意思,我很喜欢这门语言,用它来开发了很多东西,同时也知道很多公司使用python构建了很多大型稳定的系统(我们的产品应该也算吧)。

只是现在我越发觉得,看起来简单的语言,如果没有扎实的基本功底,写出来的东西也很烂,而python,恰恰给人放了一个很大的烟雾弹,你以为它有多容易,其实它是在玩你。

go

好了,终于开始说go了,let’s go!!!

我使用go的历史不长,可能也就一年多,但是它现在完全成了我最爱的语言,go具有了python开发的迅速,同时也有着c运行的性能。(当然,还是有差距的!)

网上有太多的语言之争,包括go,有人恨,有人爱。但萝卜白菜,各有所爱,对于我来说,能帮我解决问题,让我用着舒服的语言就是好语言。

go非常适用于服务端程序开发,比起用c++开发,我陡然觉得有一种很幸福的感觉,譬如对于网络编程,在c++里面,我需要自己写epoll的事件处理,而且这种异步的机制完全切分了整个逻辑,使得代码不怎么好写,我在开发libtnet的时候感触尤其深刻。但是在go里面,因为天生coroutine的支持,使得异步代码同步化了,非常利于代码的编写。

现在我的主要在项目中推动go的使用,我们已经用go搭建了一个高性能的推送服务器,后续还有几个系统会上线,而且开发的进度并不比使用python差,另外也很稳定,这让我对go的未来充满了期待。

我也用go写了很多的开源程序,也算是拿的出手了,譬如:

  • ledisdb:一个基于leveldb的提供类似redis高级数据结果的高性能NoSQL,真挺绕口的,简单点就是一个高性能NoSQL。
  • Mixer:一个mysql-proxy,现在支持通用的mysql命令代理,读写分离,以及自动主备切换。后续将要参考vitess支持分区,为此一直在恶补编译原理的知识。
  • go-log:一个类似python log模块的东西,支持多种handler,以及不同的log级别。

还有一些,可以参考我的github,譬如moonmq(一个高性能push模型的消息服务器),polaris(一个类似tornado的restful web框架),因为go,我开始热衷于开源了,并且认识了很多的好基友,这算得上一个很大的收获吧。

其它

好了,说完了上面我的长时间使用语言(至少一年以上),我也用了很多其他的语言,现在虽然使用时间比较短,但不排除后续会长久使用。

Objective-C

因为我家终于有了苹果三件套,所以决定开发app了,首要的任务就是得学会使用Objective-C。我承认这真是一门奇葩的语言,如果没有xcode的自动补齐,我真不知道写起来是神马样的感觉。

而且第一次见到了一门推荐写函数名,变量名就像写文章的语言,至少我写c++,go这些的一个函数名字不会写成一个句子。

我现在在自学iOS的开发,慢慢在整出点东西,毕竟答应给老婆的iphone做点啥的。后续干脆就写一个《小白学iOS》系列blog吧(如果我有精力!),反正对于iOS,我真是一个小白。

java

好吧,我也在android上面写过程序,build到我的S3上面去过,对于java,我的兴趣真不大,貌似自己还买过两本《java编程思想》,那时候脑袋铁定秀逗了。

但是不得不承认,java在服务器领域具有非常强的优势,很多很多的大企业采用java作为其服务器的编程语言。典型的就是淘宝,据传杭州的很多软件公司都不用java的,你用java就等于给淘宝培养人才了。(不过我发现他们很多基础组件譬如TFS这些的可是c++的哟!)

java是门好语言,只是我个人不怎么喜欢,可能我就是太小众了,只对c语言体系的感兴趣。所以很多公司我去不了,哈哈!

erlang

受《计算机程序的构造与解释》影像,我一直想学一门函数式编程语言,最开始玩的是elisp,谁叫以前我是个深度的emacser(后来竟然变成了一个vimer,再后来就是sublimer,这世界真神奇)。

后来还是决定好好学习一下erlang,也第一次领略到了函数式编程的魅力。自己唯一用erlang开发过的东西就是bt下载的客户端,不过后来发现用处不大就没继续进行下去了。(好吧,我承认当时想下岛国的东西)

学习erlang之后最大的优势在于现在能看懂很多优秀的erlang项目,譬如我在做moonmq以及公司的推送服务的时候,研究了rabbitmq,这玩意可是用erlang写的,而我竟然还能看懂,太佩服我了。

还有么?

想想自己还学了哪些语言?貌似没了,不知道awk算不算一门。看来我会得语言真不多。

后续可能会学的

逆水行舟,不进则退,计算机发展这么迅速,我也需要不断提升自己,其中学习一门新的语言可能是一个很好的提升途径,至少能为我打开一扇门。譬如,如果掌握了日文,就能更好的理解岛国片的精髓。我不会日文,所以还是个门外汉。

ruby

ruby是一门很优雅的语言,很多大神级别的人物推荐,github貌似也是ruby的幕后推手。

因为ROR的兴起,使得ruby更加流行。看来,一个好的框架库对于语言的推广帮助真挺大的。相比而言,python有django,tornado等,光选择适合自己的就得费点时间。

ruby可以算是一门完全面向对象的语言,连number这种的都是对象,而且看了几本Matz的书,觉得这哥们挺不错的,对技术的感悟很深,所以更让我有兴趣去了解ruby了。

javascript

作为一个技术人员,没一个自己的个人网站怎么行,我的阿里云都是包年买的(明年还是买国外的vps吧),自己的个人站点还无影无踪。

好吧,我完全不会javscript,看着css就头疼,没准我从一开始想自己写代码搭建个人站点这个步子就迈的太大,扯着蛋了。如果先用一个开源的框架搭建起来,再自己调整完善,可能会更好。但无论怎样,javascript这门语言还是要学习了解的,尤其是以后随着html5的流行,加之node.js疯狂流行,这门语言也会愈发的发光发热。

C Sharp

其实本来不准备跟ms的东西扯上关系的,虽然vs是一个很强大的开发工具,但是我自从换成mac之后就不准备再迁回windows。

只是c#我可能是必须要学会的,因为那个坑爹的unity3d,虽然unity3d也提供了其它语言的支持(譬如伪javascript),但是大量的开发者还是选用了c#,至少在中国我问过很多朋友,都妥妥的用c#,既然这样,我也只能考虑学习使用了。

至于我为啥蛋疼的想玩unity3d,毕竟干了很多年游戏开发,一直有自己弄一个简单小游戏的梦想,还是妥妥的unity3d吧。

自己造一个?

语言千千万,我不可能全部学会的,而且以后没准因为业务的需要,没准都会自己造一门语言,也就是DSL。不过这个貌似还离我比较遥远,编译原理的东西太差了(说多了都是泪呀)。自己写词法分析还成,后面就菜了。这也是Mixer一直没啥进展的原因。不过已经买了龙书,在学习屠龙秘籍,希望成为顶尖高手吧。

后记

写了这么多,看来随着年岁的增加,越来越啰嗦了。不是有一句古话:吾生也有涯,而知也无涯 。以有涯随无涯,殆已。不过不停地追逐不也是乐趣一件?

只是,现在我首先要做的就是向我老婆申请资金升级电脑了吧!

为什么使用Go

这里,我并不打算引起语言争论的口水仗,我并不是什么大牛,对语言的造诣也不深,只是想通过自己实际的经历,来说说为什么我在项目中选择go。

其他语言的经历

C++

在接触go之前,我已经有多年的c++开发经验。主要用在游戏服务端引擎开发以及P2P上面,那可是一段痛并快乐的时期,以至于我看到任何的程序钉子问题都觉得可以用c++这把锤子给敲定。但是对于互联网项目开发来说,除非你的团队整体的c++技术水平nb,并且有很强的代码规范,不然真可能是一场灾难,更别说我们现有团队几乎没其他人会这玩意了。

本来,我打算在现有项目中的推送系统中使用c++,并用业余时间写好了一个网络底层库libtnet,但后来还是决定打住,因为没有人能够协助我开发。令我比较欣慰的是,libtnet有一个游戏公司在使用,现处于内部测试阶段,即将放出去,我倒是很期待他们的好消息。

Lua

在做游戏的过程中,我也学会了lua这门语言,并且还有幸接触并完善了云风在Lua 不是 C++中提到的那个恐怖的lua,c++粘合层。

lua真的是一门非常好的语言,性能高,开发快速。不光游戏公司大量使用,在互联网领域,因为openresty的流行,一些公司(包括我们)也开始在web端使用lua进行开发。(颇为自豪的是还给openresty反馈过几个bug)

但是,lua因为太短小精悍,功能库并不多,很多需要自己去实现,而且,写出高性能,高质量lua代码也并不是很容易的事情。另外,因为其动态语言的特性,我们也栽了不少坑,这个后续在详说。

Python

在我来现有的团队之前,他们就已经使用python进行整个系统的开发,甚至包括客户端GUI(这对客户端童鞋当时就是一个灾难,后来换成Qt就舒爽了)。

python的好处不必说,从数不清的公司用它进行开发就知道,库非常丰富,代码简洁,开发迅速。

但是,在项目中经过两年多python开发之后,我们渐渐出现了很多问题:

  • 性能,python的性能是比较偏低的,对于很多性能热点代码,通常都会采用其他的方式实现。在我们的项目中,需要对任何API调用进行签名认证,认证服务我们开始使用的是tornado实现,但很不幸运的是,放到外网并没有顶住压力。所以我们引入openresty,专门用以解决性能问题。
  • 部署,python的库因为太丰富了,所以我们的童鞋引入了很多的库,个人感觉在pythoner的世界里面,可没有造轮子的兴趣。有时候发版本的时候,我们会因为忘记安装一个库导致程序无法运行。这可能跟我们团队没有成熟运维经验有关,后续通过salt,puppet这种发布工具应该能解决。
  • 质量,通常我们都认为,因为python代码的简洁,我们很容易的能写出高质量的代码,但是如果没有好的代码控制手段,用python也仍然能写出渣的代码,我甚至觉得因为其灵活性,可能会更容易写出烂的代码。这可以说是我们团队的教训。

这里,我并没有喷python的意思,它真的是一门好语言,我能够通过它快速的构建原型,验证我的想法,而且还一直在使用。只是在项目中,我们的一些疏忽,导致代码不可控了,到了不得不重构的地步了。

Why GO?

前面说了我的语言经历,以及项目到了重构地步的原因,但是为什么会是go呢?我们可以有很多其他的选择,譬如java,erlang,或者仍然采用python。我觉得有很多因素考量:

  • 静态,go是一门静态语言,有着强类型约束,所以我们不太可能出现在python中变量在运行时类型不匹配(譬如int + string)这样的runtime error。 在编译阶段就能够帮我们发现很多问题,不用等到运行时。(当然,这个静态语言都能做到)

  • 代码规范,很多人都比较反感go强制的编码规范,譬如花括号的位置。但我觉得,就因为强制约定,所以大家写出来的go代码样子都差不多,不用费心再去深究代码样式问题。而且我发现,因为规范统一,我很容易就能理解别人写的代码。

  • 库支持,go的库非常丰富,而且能通过go get非常方便的获取github,google code上面的第三方库(质量你自己得担着了),再不行,用go自己造轮子也是很方便的,而且造的轮子通常都比较稳定。

  • 开发迅速,不得不说,当你习惯用go开发之后,用go开发功能非常的快,相对于静态语言c++,开发的效率快的没话说,我觉得比python都不差,而且质量有保证。我们花了不到一个星期进行推送服务核心功能开发,到现在都没怎么变动,稳定运行。

  • 部署方便,因为是静态的,只需要build成一个可运行程序就可以了,部署的时候直接扔一个文件过去,不需要像python那样安装太多的依赖库。

GO特性

go现在的这个样子,有些人喜欢,有些人不喜欢,我无法知道为啥google那帮人把go设计成这样,但是我觉得,既然存在,就有道理,我只需要知道什么该用,什么不该用就可以了。

gc

GO提供了gc,这对于c++的童鞋来说,极大的减少了在内存上面犯错的机会,只是go的gc这个效率还真的不好恭维,比起java来说,还有很大的提升空间。

所以有时候写代码,我们还得根据tuning来提升gc的效率,譬如采用内存池的方式来管理大块的slice分配,采用no copy的方式来进行string,slice的互转。

不过go1.3貌似gc性能有了很大的改善,这点让我比较期待。

defer

go的defer其实是一个让人又爱又恨的东西,对于防止资源泄露,defer可是一个很不错的东西,但是滥用defer可是会让你面临很严重的内存问题,尤其是像下面的代码:

for {
    defer func(){
        //do somthing
    }
}

别以为go会在调用完成defer之后就好好的进行gc回收defer里面的东西,在我们进行内存profile的时候,发现大量的内存占用都是defer引起的。所以使用起来需要特别谨慎。

但我觉得,这个go应该会稍微改善,在go1.3里面,也有了对defer的优化。

error

也许error是一个让人争议很大的东西,现代方式的exception那里去呢?但是我觉得error能够非常明确的告诉使用者该函数会有错误返回,如果使用exception,除非文档足够详细,我还真不知道哪里就会蹦出一个异常了。

只是,go又提供了类似exception的defer,panic,recover,这是要闹哪出。

其实这篇文章我觉得已经解释的很好了,go程序的惯例是对外的API使用error,而内部错误处理可以用defer,recover和panic来简化流程。

其实这倒跟我一贯的编程准则对应,在团队在用python进行开发的时候,我们都明确要求库对外提供的API需要使用返回值来表示错误,而在内部可以使用try,catch异常机制。

interface

go提供了interface来进行抽象编程。何谓接口,最通常的例子就是鸭子的故事,“当看到一只鸟走起来像鸭子、游泳起来像鸭子、叫起来也像鸭子,那么这只鸟就可以被称为鸭子“。

在go里面,interface就是一堆方法的集合,如果某个对象实现了这些方法,那么该对象可以就算是该interface。使用interface,我们可以很方便的实现非侵入式编程,进行模块功能的替换。

对于长时间沉浸c++和python的童鞋来说,一下子要用interface来解决抽象问题,可能会很不适应。但当习惯之后,你会发现,其实interface非常的灵活方便。

写到后面

在使用的时候,我们需要知道go到底适用在什么地方,譬如我们现在也就将API服务使用go重构,我们可没傻到用go去替换openresty。

总之,go是一门很新的语言,国内也已经有很多公司开始吃这个螃蟹,也有成功的例子了,而我们也正开始了这段旅程。

简易的C++协程库

起因

在第一个版本的libtnet开发完成之后,我一直在思考如何让异步方式的网络编程更加简单。

虽然libtnet通过c++ shared_ptr以及function等技术很大程度上面解决了异步代码编写的一些问题,但是仍然会出现代码逻辑被强制拆分的情况。而这个则是项目中童鞋无法很好的使用其进行开发的原因。

所以我考虑让libtnet支持coroutine。

Coroutine

第一次接触coroutine的概念是在lua里面,记得当时想了很久才算弄明白了coroutine的使用以及原理。在lua中,coroutine的使用如下:

co = coroutine.create(function ()
        print("begin yield")
        coroutine.yield()
        print("after yield")
    end)

coroutine.resume(co)
print("after resume")

coroutine.resume(co)

我们可以通过resume执行一个新创建或者已经被挂起的coroutine,通过yield挂起当前的coroutine,这样就可以实现类似多线程方式下面的多任务调度。

至于coroutine的原理,很多地方都有说明,主要就在于每个coroutine都有自己的堆栈,这样当coroutine挂起的时候,它的当前执行状态会被完整保留,下次resume的时候就可以接着执行了。

而使用coroutine的好处,我觉得最大的一点在于它将拆分的异步逻辑同步化了,更利于代码编写。

在使用python tornado的时候,我们开始阶段写了太多的callback回调,以至于代码的维护非常困难,而这个则在引入greenlet后有了明显好转。

而后续在使用go语言中,因为它原生的支持coroutine(其实在go里面更准确的说法应该是goroutine),写代码非常的方便,所以现在go已经成为了我服务器的首选开发语言,我也用它开发了多个项目(如mixer,一个mysql proxy),并且已经在公司项目中实施。

当然,使用coroutine并不是毫无缺点的:

  • 每个coroutine都需要维护自己的堆栈,当我们需要创建数以百万计的coroutine的时候,内存的开销就需要考虑了。
  • coroutine的切换,都需要保留当前的上下文环境,以便于下次resume的时候接着执行,如果coroutine切换频繁,开销也不小。

libcoro

很早之前使用luajit的时候,我就知道可以在c++中实现coroutine的功能,在linux中,这通过makecontext,swapcontext等相关函数实现。虽然也可以通过setjmp/longjmp这两个古老的函数实现,但看了luajit的coco就知道,即使在linux下面,它也需要写很多define宏去适配。

所以,我只考虑使用makecontext这套函数族来实现coroutine。虽然swapcontext会有性能问题,详见这里,但早期我还不打算对其进行性能优化。

libcoro是一个简单的c++ coroutine库,只支持linux(因为我们的服务器只有linux的)。

在接口上面,libcoro参考的是lua的coroutine的接口设计,使用非常简单:

void func1()
{
    coroutine.yield();
}

void func2(Coro_t co1)
{
    coroutine.resume(co1);    
    coroutine.yield();
}

void func()
{
    Coro_t co1 = coroutine.create(std::bind(&func1));    
    coroutine.resume(co1);    
    Coro_t co2 = coroutine.create(std::bind(&func2, co1));
    coroutine.resume(co2);
    coroutine.resume(co2);
}

int main()
{    
    Coro_t co = coroutine.create(std::bind(&func));
    coroutine.resume(co);
    return 0;
}
  • coroutine.create创建一个coroutine,参数为一个std::function,这样我们就可以通过std::bind非常方便的实现函数闭包了。
  • coroutine.resume唤醒一个挂起或者新建的coroutine。
  • coroutine.yield挂起当前coroutine。
  • coroutine.running获取当前运行的coroutine,如果是主线程调用,则返回0。
  • coroutine.status获取coroutine的状态。

后续我考虑将libtnet支持coroutine,不过这可能会成为一个新的网络库了。

Lua与C接口层开发

lua与c的交互

关于lua和c的交互,主要有两个方面,一是lua调用c的函数,而另一个则是c调用lua函数。而这些都是通过lua stack来进行的。

c调用lua

在c里面使用lua,主要是通过lua_call这类函数,下面来自lua manual的例子:

lua_getglobal(L, "f");                  /* function to be called */
lua_pushstring(L, "how");                        /* 1st argument */
lua_getglobal(L, "t");                    /* table to be indexed */
lua_getfield(L, -1, "x");        /* push result of t.x (2nd arg) */
lua_remove(L, -2);                  /* remove 't' from the stack */
lua_pushinteger(L, 14);                          /* 3rd argument */
lua_call(L, 3, 1);     /* call 'f' with 3 arguments and 1 result */
lua_setglobal(L, "a");                         /* set global 'a' */

该例子等同于直接在lua里面调用 a = f(“how”, t.x, 14)。
通过上面的例子可以看到,在c中使用lua是一件很容易的事情,首先获取需要调用的lua函数,然后将其需要的参数依次压入stack,然后通过lua_call调用,该函数调用的返回值也压入stack,供c去获取。

lua调用c

对于lua调用c,我们首先需要将c函数注册给lua,而注册给lua的函数,需要满足 int (*lua_CFunction)(lua_State* pState) 这种类型。如下例子:

int multi(lua_State* pState)
{
    int data1 = int(lua_tonumber(pState, 1));
    int data2 = int(lua_tonumber(pState, 2));
    lua_pushnumber(pState, data1 * data2);
    return 1;
}

lua_register(pState, multi, "multi");

#for use in lua
#a = multi(10, 20)

我们通过lua_register将mutli函数注册给lua,该函数接受两个参数,并且有一个返回值。当lua调用multi的时候,会将参数压入stack,所以我们可以通过lua_tonumber(pState, 1)和lua_tonumber(pState, 2)来获取,其中1为第一个参数10,2为第二个参数20。当运行完成之后,multi函数通过lua_pushnumber将结果压入lua堆栈,并通过return 1告知lua有一个返回值,为200。

可以看到,在lua中使用c也是一件很简单的事情。

lua mainly or c mainly

通过上面的例子可以看出,lua与c是很方便的交互的,但是在实际的游戏项目中,我们首先必须确定的一个问题就是,代码逻辑是以lua为主还是以c为主。

  • lua为主的游戏就是逻辑主要由lua负责,核心的对性能要求较高的逻辑则由c负责,游戏中的数据大多由lua负责。
  • c为主的游戏则是逻辑主要由c负责,lua只是负责简单的配置。

这两种方式都有优劣,对于实际游戏项目来说,个人认为,应该采用lua为主,c作为高性能核心的方式。之所以这样选择,是因为游戏的逻辑变动很大,我们需要快速的进行代码迭代,这个对于lua来说非常方便。而对于核心引擎,因为变化不大,同时对性能要求较高,所以采用c是一个很好的选择。

reg helper

在实际的游戏项目中,我们会遇到这样一个问题,假设c提供的函数为 int func(int a, int b),如果这个函数要提供给lua使用,我们需要写一个对应的注册函数,如下:

int func_wrapper(lua_State* pState)
{
    int a = int(lua_tonumber(pState, 1));
    int b = int(lua_tonumber(pState, 2));
    int ret = func(a, b);
    lua_pushnumber(pState, ret);
    return 1;
}

lua_register(pState, func_wrapper, "func");

对于任意的c函数,我们需要写一个对应的wrapper用来注册给lua。如果项目中只有几个c函数,那么无所谓,但是如果需要注册给lua的c函数很多,那么对于每一个c函数写一个wrapper,是一件很不现实的事情。并且如果c函数的参数或者返回值有变化,我们同时需要修改对应的wrapper函数。基于上述原因,我们需要一套自动机制,能够将任意的c函数注册给lua使用。实际来说,我们需要提供一个函数,对于任意的c函数func,我们只需要调用register(func, “func”),那么就能直接注册给lua使用。

traits

首先,我们必须面对的问题就是,不同的c函数,参数和返回值是不一样的,譬如对于int类型的参数,我们需要通过lua_tonumber获取数据,而对于const char* 类型的参数,我们需要通过lua_tostring来获取,同理对于返回值也一样。所以我们需要一套机制,根据c函数不同的参数和返回值类型来调用lua对应的stack操纵函数。我们可以通过c++ traits来实现。

我们提供如下一套函数:

template<typename T>
struct TypeHelper{};
bool getValue(TypeHelper<bool>, lua_State* pState, int index)
{
    return lua_toboolean(pState, index) == 1;
}
char getValue(TypeHelper<char>, lua_State* pState, int index)
{
    return static_cast<char>(lua_tonumber(pState, index));
}
int getValue(TypeHelper<int>, lua_State* pState, int index)
{
    return static_cast<int>(lua_tonumber(pState, index));
}
void pushValue(lua_State* pState, bool value)
{
    lua_pushboolean(pState, int(value));
}

void pushValue(lua_State* pState, char value)
{
    lua_pushnumber(pState, value);
}

void pushValue(lua_State* pState, int value)
{
    lua_pushnumber(pState, value);
}

通过traits技术,对于不同的参数类型,我们可以调用对应的getValue函数,来从lua获取实际的数据,而对于返回值,通过c++自动的参数匹配,就能调用对应的pushValue函数。

CCallHelper

上面解决了类型匹配的问题,下面就需要提供wrapper函数,用以封装c函数。这里我们提供call helper类来实现。

template<typename Ret>
class CCallHelper
{
public:
    static int call(Ret (*func)(), lua_State* pState)
    {
        Ret ret = (*func)();
        pushValue(pState, ret);
        return 1;
    }

    template<typename P1>
    static int call(Ret (*func)(P1), lua_State* pState)
    {
        P1 p1 = getValue(TypeHelper<P1>(), pState, 1);
        Ret ret = (*func)(p1);
        pushValue(pState, ret);
        return 1;
    }
};

CCallHelper提供了静态的call函数,第一个参数就是实际c函数,通过函数模板可以进行任意c函数的匹配,这里只提供了匹配无参数和一个参数类型的c函数模板,我们可以扩展到支持任意参数个数,但也别太多了。因为对于任意c函数来说,可能有一个返回值,也可能没有返回值,那么我们如何匹配没有返回值的c函数呢?这里就是为什么我们需要CCallHelper的原因。在c++中,是不支持函数级别的模板特化的,但是类却可以,所以我们通过特化CCallHelper来匹配无返回值的c函数。如下:

template<>
class CCallHelper<void>
{
public:
    static int call(void (*func)(), lua_State* pState)
    {
        (*func)();
        return 0;
    } 

    template<typename P1>
    static int call(void (*func)(P1), lua_State* pState)
    {
        P1 p1 = getValue(TypeHelper<P1>(), pState, 1);
        (*func)(p1);
        return 0;
    }
};

CCallDispatcher

通过CCallHelper::call(func, pState),我们就可以与lua进行交互,那么又如何调用到相应的CCallHelper呢?这里我们通过CCallDispatcher来进行,如下:

template<typename Func>
class CCallDispatcher
{
public:
    template<typename Ret>
    static int dispatch(Ret (*func)(), lua_State* pState)
    {
        return CCallHelper<Ret>::call(func, pState);
    }

    template<typename Ret, typename P1>
    static int dispatch(Ret (*func)(P1), lua_State* pState)
    {
        return CCallHelper<Ret>::call(func, pState);
    }
};

通过CCallDispatcher,我们就可以将不同的c函数dispatch到不同的CCallHelper上面。

CCallRegister and regFunction

解决了c函数派发调用的问题,最后我们就需要处理如何将任意的c函数注册给lua,代码如下:

template<typename Func>
class CCallRegister
{
public:
    static int call(lua_State* pState)
    {
        Func* func = static_cast<Func*>(lua_touserdata(pState, lua_upvalueindex(1));
        return CCallDispatcher<Func>::dispatch(*func, pState);
    }
};

template<typename Func>
void regFunction(lua_State* pState, Func func, const char* funcName)
{
    int funcSize = sizeof(Func);
    void* data = lua_newuserdata(pState, funcSize);
    memcpy(data, &func, funcSize);

    lua_pushcclosure(pState, CCallRegister<Func>::call, 1);
    lua_setglobal(pState, funcName);
}

首先,我们提供CCallRegister类,里面提供了一个static的call函数,该函数满足lua注册格式,所以实际我们是将该函数注册给lua,在call函数里面,我们通过lua_touserdata(pState, lua_upvalueindex(1))来获取实际的func,然后传递给CCallDispatcher进行派发。而将call注册则是通过regFunction,该函数将实际的c函数func存储在一个userdata中,然后将该userdata绑定到对应的CCallRgister call上面,作为一个upvalue,这样当在lua里面调用call函数的时候,通过lua_upvalueindex获取对应的upvalue,则可以取到实际的c函数。

一些设计上面的考虑

上述reghelper的实现,我已经放到github luahelper上面,并且在max os,gcc 4.2,lua5.2环境下面测试通过。

这里谈一些设计上面的问题,首先,我说的任意c函数,参数和返回值只能是基本数值类型,如bool,char,short,int,long,float,double以及字符串类型char*等,这里我并没有提供复杂类型譬如class,struct的支持。之所以这样考虑,是因为我想保证lua与
c交互的简单,云风曾经说过lua不是c++,我本人当年也曾经用了2年的时间做了同样的事情。但是实现了这套东西,功能是狠强大了,以至于可以把lua当成c++来用了,但是这真的是使用lua正确的方式吗?我现在觉得,引入复杂的结合层,反而在某些时候会带来更大的复杂性,导致语言侧重点的混淆。所以有时候,我反而觉得,对于这种语言的交互,可能使用其他方式,譬如json,反而来的更容易。

写在后面的话

对于lua和游戏开发的一些东西,其实一直想写,但是以前因为很多方面的原因而中途放弃。现在重新开始,有几个方面的原因,一个在于仍然对于游戏开发的热爱,做了4年的游戏开发,虽然现在从事云存储方面的研究,但是对游戏热情依旧。另一个方面在于lua5.2的发布,觉得是应该对以前游戏人生做一个总结了。

如果需要更强大的lua与c的交互,我觉得swig可能更合适。

Libtnet 百万连接测试

最近在用go语言做一个挂载大量长连接的推送服务器,虽然已经完成,但是内存占用情况让我不怎么满意,于是考虑使用libtnet来重新实现一个。后续我会使用comet来表明推送服务器。

对于comet来说,单机能支撑大量的并发连接,是最优先考虑的事项。虽然现在业界已经有了很多数据,说单机支撑200w,300w,但我还是先把目标定在100w上面,主要的原因在于实际运行中,comet还会有少量逻辑功能,我得保证在单机挂载100w的基础上,完全能无压力的处理这些逻辑。

CometServer Test

首先我用libtnet简单写了一个comet server。它接受http请求,并将其挂起,过一段随机时间之后在返回200。

void onTimeout(const TimingWheelPtr_t& wheel, const WeakHttpConnectionPtr_t& conn)
{
    HttpConnectionPtr_t c = conn.lock();
    if(c)
    {
        c->send(200);
    } 
}

void onHandler(const HttpConnectionPtr_t& conn, const HttpRequest& request)
{
    int timeout = random() % 60 + 30;
    comet.wheel->add(std::bind(&onTimeout, _1, WeakHttpConnectionPtr_t(conn)), timeout * 1000);
}

int main()
{
    TcpServer s;        
    s.setRunCallback(std::bind(&onServerRun, _1));
    HttpServer httpd(&s);
    httpd.setHttpCallback("/", std::bind(&onHandler, _1, _2));
    httpd.listen(Address(11181));
    s.start(8);
    return 0; 
}

可以看到comet server只是负责了挂载长连接的事情,而没有消息的推送。在实际项目中,我已经将挂载连接和推送消息分开到两个服务去完成。所以这里comet仅仅是挂载连接测试。

测试机器准备

因为linux系统上面一个网卡tcp连接端口数量是有限制的,我们调整ip_local_port_range使其能支撑60000个tcp连接:

net.ipv4.ip_local_port_range = 1024 65535

对于100w连接来说,我们至少需要16台机器,但实际我只有可怜的3台4G内存的虚拟机。所以就要运维的童鞋在每台机器上面装了6块网卡。这样我就能建立100w的连接了。

测试客户端也非常简单,每秒向服务器请求1000个连接,但是需要注意的是,因为一台机器上面有多块网卡,所以在创建socket之后,我们需要将socket绑定到某一块网卡上面。

实际测试中,因为内存问题,每台机器顶多能支撑34w左右的tcp连接,对我来说已经足够,所以也懒得去调优了。

CometServer Linux调优

首先我们需要调整最大打开文件数,在我的机器上面,nr_open最大的值为1048576,对我来说已经足够,所以我将最大文件描述符数量调整为1040000。

fs.file-max = 1040000

然后就是对tcp一些系统参数的调优:

net.core.somaxconn = 60000
net.core.rmem_default = 4096
net.core.wmem_default = 4096
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 4096 16777216
net.ipv4.tcp_wmem = 4096 4096 16777216
net.ipv4.tcp_mem = 786432 2097152 3145728
net.core.netdev_max_backlog = 60000
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_max_syn_backlog = 60000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_max_orphans = 131072
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.tcp_max_tw_buckets = 60000
net.netfilter.nf_conntrack_max = 1000000
net.netfilter.nf_conntrack_tcp_timeout_established = 1200

对于如何调节这些值,网上都是各有各的说法,建议直接man 7 tcp。我在实践中也会通过查看dmesg输出的tcp错误来动态调节。这里单独需要说明的是tcp buffer的设置,我最小和默认都是4k,这主要是考虑到推送服务器不需要太多太频繁的数据交互,所以需要尽可能的减少tcp的内存消耗。

测试结果

实际的测试比较让我满意。

cometserver test8个进程cpu消耗都比较低,因为有轮训timing wheel然后再发送200的逻辑,所以铁定有cpu消耗,如果只是挂载,cpu应该会更低。

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                       
 4685 root      20   0  187m 171m  652 S 19.9  1.1   2:19.20 cometserver_test                                                                                                
 4691 root      20   0  191m 175m  656 S 16.6  1.1   2:17.80 cometserver_test                                                                                                
 4686 root      20   0  170m 155m  652 S 16.3  1.0   2:09.54 cometserver_test                                                                                                
 4690 root      20   0  183m 167m  652 S 16.3  1.1   2:11.44 cometserver_test                                                                                                
 4692 root      20   0  167m 152m  652 S 16.3  1.0   2:11.29 cometserver_test                                                                                                
 4689 root      20   0  167m 152m  652 S 15.3  1.0   2:03.08 cometserver_test                                                                                                
 4687 root      20   0  173m 158m  652 S 14.3  1.0   2:07.34 cometserver_test                                                                                                
 4688 root      20   0  129m 114m  652 S 12.3  0.7   1:35.77 cometserver_test

socket的统计情况:

[root@localhost ~]# cat /proc/net/sockstat
sockets: used 1017305
TCP: inuse 1017147 orphan 0 tw 0 alloc 1017167 mem 404824
UDP: inuse 0 mem 0
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0

可以看到,总共有1017147个tcp链接,同时占用了将近4G(1017167是页数,需要乘以4096)的内存。

系统内存的情况:

[root@localhost ~]# free
             total       used       free     shared    buffers     cached
Mem:      16334412   11210224    5124188          0     179424    1609300
-/+ buffers/cache:    9421500    6912912
Swap:      4194296          0    4194296

系统有16G内存,还有5G可用,所以不出意外单机应该还能承载更多的tcp连接。

总结

使用libtnet开发的一个简单的comet server支撑了百万级的连接,加深了我对其应用的信心。

libnet地址https://github.com/siddontang/libtnet,欢迎围观。

Libtnet HTTP实现

HTTP

libtnet提供了简单的http支持,使用也很简单。

一个简单的http server:

void onHandler(const HttpConnectionPtr_t& conn, const HttpRequest& request)
{
    HttpResponse resp;
    resp.statusCode = 200;
    resp.setContentType("text/html");
    resp.body.append("Hello World");    
    conn->send(resp);
}

TcpServer s;
HttpServer httpd(&s);
httpd.setHttpCallback("/test", std::bind(&onHandler, _1, _2));
httpd.listen(Address(80));
s.start(4);

我们对http server的“/test”注册了一个handler,当用户访问该url的时候,就会显示”Hello World”。

同样,http client的使用也很简单:

void onResponse(IOLoop* loop, const HttpResponse& resp)
{
    cout << resp.body << endl;
    loop->stop();
}

IOLoop loop;
HttpClientPtr_t client = std::make_shared<HttpClient>(&loop);
client->request("http://127.0.0.1:80/test", std::bind(&onResponse, &loop, _1));
loop.start(); 

这里,我们使用了一个http client,向server请求”/test”的内容,当服务器有响应之后,会调用响应的回调函数。

HTTP Parser

对于http的解析,我采用的是http parser,因为它采用的是流式解析,同时非常容易集成进libtnet。

使用http parser只需要设置相应的回调函数即可。http parser有如下几种回调:

  • message begin,解析开始的时候调用
  • url,解析url的时候调用
  • status complete,http response解析status的时候调用
  • header field,解析http header的field调用
  • header value,解析http header的value调用
  • headers complete,解析完成http header调用
  • body,解析http body调用
  • message complete,解析完成调用

这里特别需要注意的是http header的解析,因为http parser将其拆分成了两种回调,所以我们在处理的时候需要记录上一次header callback是field的还是value的。在解析field的时候,如果上一次是value callback,那我们就需要将上一次解析的field和value保存下来,而该次的解析则是一个新的field了。

另外,http parser还提供了upgrade的支持,所以我们很方便的就能区分该次请求是否为websocket。

Websocket

libtnet也提供了websocket的支持,现阶段,只支持RFC6455

当libtnet通过http parser发现该次请求为websocket的时候,就进入了websocket的流程。websocket的使用也很简单,当握手成功之后,后续的所有通讯就是纯粹的tcp通信了。

一个简单的websocket server:

void onWsCallback(const WsConnectionPtr_t& conn, WsEvent event, const void* context)
{
    switch(event)
    {
        case Ws_CloseEvent:
            break;
        case Ws_MessageEvent:
            {
                const string& str = *(const string*)context;
                conn->send(str);
            }
            break;
        case Ws_PongEvent:
            break;
        default:
            break;
    }
}

TcpServer s;
HttpServer httpd(&s);
httpd.setWsCallback("/push/ws", std::bind(&onWsCallback, _1, _2, _3));    
httpd.listen(Address(80));
s.start();

可以看到,websocket的callback机制也类似于libtnet connection的callback机制,用户需通过event + context的方式来处理该次回调的数据。

libtnet对websocket的frame的处理参照的是tornado的websocket模块。也能够组合多frame的数据,外部只需要关注Ws_MessageEvent即可。

websocket client的实现也很简单:

void onWsConnEvent(const WsConnectionPtr_t& conn, WsEvent event, const void* context)
{
    switch(event)
    {
        case Ws_OpenEvent:
            conn->send("Hello world");
            break;    
        case Ws_MessageEvent:
            {
                const string& msg = *(const string*)context;

                LOG_INFO("message %s", msg.c_str());
                conn->close();                        
            }
            break;
        default:
            break;
    }    
}

IOLoop loop;
WsClientPtr_t client = std::make_shared<WsClient>(&loop);    
client->connect("ws://127.0.0.1:80/push/ws", std::bind(&onWsConnEvent, _1, _2, _3));
loop.start();

Libtnet Connection实现

libtnet只支持IPv4 TCP Connection,之所以这么做都是为了使得实现尽可能的简单。我们主要在Connection类中封装了对tcp连接的操作。

Connection继承自std::enable_shared_from_this,也就意味着外部我们会操作其shared_ptr,libtnet几乎所有的对象都采用智能指针的方式来进行内存管理。

当Connection创建成功之后,会通过IOLoop的addHandler接口,将其绑定到ioloop上面:

ConnectionPtr_t conn = shared_from_this();
m_loop->addHandler(m_fd, TNET_READ, std::bind(&Connection::onHandler, conn, _1, _2));

因为我们直接在std::bind里面使用了shared_ptr,所以ioloop自然引用了该Connection,外部不需要在存储Connection,以防内存泄露。

对于一个connection而言,它只可能有几种状态,

  • Connecting,表明正在尝试连接,发生在connect返回EINPROGRESS。
  • Connected,连接已经建立成功,发生在connect成功或者accept成功。
  • Disconnecting,表明连接正在断开,发生在用户主动调用shutDown之后。
  • Disconnected,连接已经断开,这时候对应的socket也会被close掉。

Event Callback

在Connection中,我们使用一个event callback来绑定相应事件的回调。主要有如下connection event:

  • Conn_EstablishedEvent, 当server accept成功,创建了Connection对象之后,触发。
  • Conn_ConnectEvent,当client connect成功,触发。
  • Conn_ConnectingEvent,当client connect返回EINPROGRESS,触发。
  • Conn_ReadEvent,当连接可读,触发。
  • Conn_WriteCompleteEvent,当发送的数据都发送完毕,触发。
  • Conn_ErrorEvent,当连接有错误发生,触发。
  • Conn_CloseEvent,当连接主动或者被动关闭,触发。

event callback原型如下:

typedef shared_ptr<Connection> ConnectionPtr_t;
typedef std::function<void (const ConnectionPtr_t&, ConnEvent, const void* context)> ConnEventCallback_t;

对应不同的事件,触发的时候context的内容不同。现阶段,只有ReadEvent的时候context为StackBuffer,原型如下:

class StackBuffer
{
public:
    StackBuffer(const char* buf, size_t c) : buffer(buf), count(c) {}

    const char* buffer;
    size_t count;    
};

当连接可读的时候,Connection会将数据读取到栈上面,并用StackBuffer来指代,这样当外部处理ReadEvent的时候就能通过将context转换成StackBuffer获取到读取的数据。

下面简单说明一下一些设计上面的取舍:

  • 为什么只提供一个event callback,而不提供read callback,write complete callback,close callback多个回调接口?

    libtnet的所有callback都采用的是std::function实现,而该对象占用32字节,如果每个event都提供一个对应的callback,那么内存的开销会有点大,同时大部分时候很多callback我们是不感兴趣的。

    还有一个重要的原因在于只提供一个event callback,外部的一些对象就可以通过该callback跟Connection绑定,也就是将其自身的生命周期与Connection绑定在了一起,当Connection删除的时候该对象也自行删除。libtnet中,HttpConnection,WsConnection都是采用该方法,因为对于一个Http连接来说,如果底层的Tcp连接都断开无效了,基于Tcp的Http连接自然就无效了。

  • Connection为什么不缓存读取的数据,而是交由外部callback去处理?

    Connection作为一个底层的类,对于读取的数据,并不知道具体需要如何处理,所以还不如将数据直接发到外层,供上层实际的应用逻辑处理。但是如果后续Connection考虑支持ssl,那么就需要进行缓存数据了。

Write

Connection建立之后,默认只会在ioloop中设置TNET_READ事件,因为epoll采用的水平触发模式,如果直接设置TNET_WRITE事件,那么epoll会一直通知socket可写,但实际上并没有可以发送的数据。

所以,libtnet采用如下的方式进行数据发送:

  • 直接调用writev函数进行数据发送
  • 如果数据未发送完毕,则向ioloop注册TNET_WRITE事件,下次触发可写的时候继续发送,直至发送成功,清除TNET_WRITE事件。

另外,在发送的时候,我们还需要考虑signal pipe的情况,所以需要忽略该singal。使用如下方式:

class IgnoreSigPipe
{
public:
    IgnoreSigPipe()
    {
        signal(SIGPIPE, SIG_IGN);    
    }    
};

static IgnoreSigPipe initObj;

当libtnet启动的时候,就忽略了signal pipe信号。虽然这样做稍微有一点副作用,但大部分时候我们并不需要关注SIGPIPE信号。

Kick Off Connection

通常,为了处理不活跃连接,程序都会将每个connection设置一个timer,如果timer到了该连接仍然没有交互,则会删除该连接,否则则继续更新timer。另一种做法就是提供一个time wheel,将connection放置在该wheel中,如果有交互,则在wheel中移动。

libtnet采用了一种更简单,但是精度比较差的做法。

当server成功创建一个connection之后,将会添加到一个ConnChecker中,checker保存的是该connection的weak_ptr。每隔一段时间,checker检查一批connection:

  • 如果connection weak_ptr无法lock提升至shared_ptr,证明该连接已经删除,checker直接移除。
  • 如果connection处于connecting状态,并且超过了设置的最大连接超时时间,shutDown该connection。
  • 如果connection处于connected状态,并且在一段时间内没有任何交互,shutDown。

ConnChecker的检查间隔以及每次检查步数都可以通过外部设置。使用ConnChecker虽然简单,但是在连接数过大的情况下面,一些过期的connection不能立刻被清理掉。对于这个问题,我觉得可以接受,一个连接一秒之后被关闭还是两秒之后被关闭,差别真的不大。如果我们真的需要对一些connection做精确的时间控制,那直接可以对其使用timer。

Libtnet事件循环

libtnet采用的是prefork + event loop的架构方式,prefork就是server在启动的时候预先fork多个子进程同时工作,而event loop则是基于epoll的事件处理机制。

在最新的linux系统中,提供了timerfd,eventfd,signalfd,加上原先的socket,大部分功能都可以抽象成io事件来处理了。而在libtnet中,这一切的基础就是IOLoop。

类似于tornado,libtnet的IOLoop也提供了相似的接口。其中最核心的就是以下三个:

typedef std::function<void (IOLoop*, int)> IOHandler_t;

int addHandler(int fd, int events, const IOHandler_t& handler);
int updateHandler(int fd, int events);
int removeHandler(int fd);  

对于任意的IO,我们可以注册感兴趣的事件(TNET_READ和TNET_WRITE),并绑定一个对应的callback回调。

callback的回调采用的是std::function的方式,这也就意味着,你可以在外部通过std::bind绑定任意不同的实现,再加上shared_ptr技术模拟闭包。

假设现在我们需要创建了一个socket对象,并将其添加到IOLoop中,我们可以这么做:

std::shared_ptr<Connection> conn = std::make_shared<Connection>(socketfd);

ioloop->addHandler(socketfd, TNET_READ, std::bind(&Connection::onHandler, conn, _1, _2));

这样,当该socket有读事件发生的时候,对应的onHandler就会被调用。在这里,我是用了shared_ptr技术,主要是为了方便进行对象生命周期的管理。

在上面的例子中,因为std::bind的时候引用了conn,只要不将socketfd进行removeHandler,conn对象就会一直存在。所以libtnet在IOLoop内部,自行维护了conn对象的生命周期。外面不需要在将其保存到另一个地方(如果真保存了该shared_ptr的conn,反而会引起内存泄露)。在libtnet的基础模块中,我都使用的是weak_ptr来保存相关对象,每次使用都通过lock来判定是否该对象存活。

在IOLoop内部,我使用一个vector来存放注册的handler,vector的索引就是io的fd。这样,我们通过io的fd就可以非常快速的查找到对应的handler了。为什么可以这样设计,是因为在linux系统中,进程中新建文件的file descriptor都是系统当前最小的可用整数。譬如,我创建了一个socket,fd为10,然后我关闭了该socket,再次新建一个socket,这时候新的socket的fd仍然为最小可用的整数,也就是10。

EPoll

提到linux下面的高性能网络编程,epoll是一个铁定绕不开的话题,关于epoll的使用,网上有太多的讲解,这里就不展开了。

libtnet在Poller中集成了epoll,参考了libev的实现。epoll有两种工作模式,水平触发和边沿触发,各有利弊。libtnet使用的是水平触发方式,主要原因在于水平触发方式在有消息但是没处理的时候会一直通知你处理,实现起来不容易出错,也比较简单。

fork and epoll_create

这里顺便记录一下我在实现prefork模型的时候遇到的一个坑。这个问题就是epoll fd应该在fork之前还是之后创建?

大家都知道,linux fork的时候采用COW(copy on write)方式复制父进程的内容,然后我想当然的以为各个子进程会拥有独立的epoll内核空间,于是在fork之前创建了epoll fd。但是后面我却惊奇的发现一个子进程对epoll的操作竟然会影响另一个子进程。也就是说,各个子进程共享了父进程的epoll内核空间。

所以,epoll fd的创建应该在fork之后,各个子进程独立创建。

Example

Timer

IOLoop提供了一个简单的runAfter函数,用以实现定时器功能,使用非常简单:

void func(IOLoop* loop)
{
    cout << "hello world" << endl;
    loop->stop();
}

IOLoop loop;
loop.runAfter(10 * 1000, std::bind(&func, &loop));
loop.start();

loop启动十秒之后,会打印hello world,然后整个loop退出。更多定制化的timer使用,可以使用libtnet提供的Timer class。

Callback

libtnet是一个单线程单ioloop的模型,但是不排除仍然会有其他线程希望与IOLoop进行通信,所以IOLoop提供了addCallback功能,这是libtnet唯一一个线程安全的函数。因为加入callback是一个很快速的操作,IOLoop使用了spinlock。在IOLoop每次循环的末尾,会将全部的callback取出,依次执行。

void callback(IOLoop* loop)
{
    cout << "tell to exit" << endl;
    loop->stop();
}

IOLoop loop;
loop.addCallback(std::bind(&func, &loop));
loop.start();

高性能网络库Libtnet介绍

libtnet是一个用c++编写的高性能网络库,它在设计上面主要参考tornado,为服务端网络编程提供简洁而高效的接口,非常易于使用。

Echo Server

void onConnEvent(const ConnectionPtr_t& conn, ConnEvent event, const void* context)
{
    switch(event)
    {
        case Conn_ReadEvent:
            {
                const StackBuffer* buffer = static_cast<const StackBuffer*>(context);
                conn->send(string(buffer->buffer, buffer->count));
            }
            break;
        default:
            break;
    }    
}

int main()
{
    TcpServer s;
    s.listen(Address(11181), std::bind(&onConnEvent, _1, _2, _3));

    s.start();

    return 0;
}

当程序启动,服务监听本地11181端口,我们使用telnet测试:

root@tnet:~# telnet 127.0.0.1 11181
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
hello world
hello world

可以看到,libtnet在使用上面非常简单,在listen的时候,指定一个回调函数,当有新的连接到来的时候,该回调函数就会与该connection进行绑定,这样该connection的任何事件都能通过回调进行处理。

在上面那个例子中,我们只关心了connection的ReadEvent,也就是读事件,然后将读取到的所有数据原封不动的转发回去。

Http Server

void onHandler(const HttpConnectionPtr_t& conn, const HttpRequest& request)
{
    HttpResponse resp;
    resp.statusCode = 200;
    resp.body.append("Hello World");

    conn->send(resp);
}

int main()
{
    TcpServer s;
    HttpServer httpd(&s);   
    httpd.setHttpCallback("/abc", std::bind(&onHandler, _1, _2));

    httpd.listen(Address(11181));    
    s.start(4);

    return 0;
} 

当server启动,程序使用本机11181端口提供http服务。我们使用curl测试。

curl http://127.0.0.1:11181/abc

return: hello world

可以看到,使用http server也非常简单,我们只需要对相应的路径绑定一个callback回调,当有请求发生的时候,对应的callback执行。

使用benchmark测试,发现性能也不错RPS能到16000+,在512MB,单核CPU下面进行ab压测,具体可以参考benchmark

Webscoket Server

void onWsCallback(const WsConnectionPtr_t& conn, WsEvent event, const void* context)
{
    switch(event)
    {
        case Ws_MessageEvent:
            {
                const string& str = *(const string*)context;
                conn->send("hello " + str);
            }
            break;
        default:
            break;
    }
}

int main()
{
    TcpServer s;

    HttpServer httpd(&s);

    httpd.setWsCallback("/push/ws", std::bind(&onWsCallback, _1, _2, _3));    

    httpd.listen(Address(11181));

    s.start();

    return 0; 
}

libtnet同样提供了websocket RFC6455的支持,使用方法同http server,只需要对相应的path注册特定的回调,就可以很方便的进行websocket交互。

Client

libtnet不光提供了server层面的相关功能,同时也集成了http clientwebsocket client以及redis client。使得libtnet也能方便的进行客户端网络功能的开发。对于具体的使用,可以参考example

设计上面的考量

libtnet只支持linux版本,虽然做一个跨平台的通用库是一件吸引力非常大的事情,但是综合考虑之后,我决定只做linux版本的,主要有以下几个原因:

  • Linux下面使用prefork + epoll是一种非常高效的网络编程模型,性能强悍,实现简单。虽然unix下面有kqueue,windows下面有IOCP,但是没必要为了适配所有得操作系统将代码写的复杂。
  • Linux在系统层面上面就提供了很多高性能的函数,譬如timerfd,eventfd等,不光性能提升,同时也简化了很多代码实现。
  • Linux在服务器编程领域的使用率很高,专门做精一个平台就够了。

因为高性能的网络编程通常都是使用异步的编程方式,所以经常可以看到代码被异步拆的特别分散,不利于编写。所以我在libtnet里面大量的使用了c++ bind以及shared_ptr技术,用来模拟函数闭包,以及解决对象生命周期管理问题,简化代码的编写。并且我也使用了c++ 0x相关技术,gcc的版本至少要在4.4以上。

对于如何设计以及使用libtnet,后续我会有更加详细的说明。