这里需要特别说明一点的是, 对于tcp字节流的处理, chaos底层有默认的机制, 当一个完整的数据包被读取之后, handle_packet就会被调用, 可以看到, 服务在收到完整的数据包之后, 发送了同样的内容给对端.

默认策略的实现就在test_server_echo_conn_t所继承的default_conn_strategy_t中, 该类对所有tcp字节流的处理流程是:

如何生成并应用chaos到自己的项目

chaos目前提供的链接方式是以静态库(.a)存在的, 你可以运行根目录下的build_all.sh脚本进行生成(需要安装automake软件), 你不需要再安装任何第三方库即可编译整个chaos, 当编译完成后会在根目录生成lib临时目录,里面即包含相应的chaos静态库, 之后可参照test目录下的用例的方式链接到自己的项目中.

网络库之外看chaos

    之前我曾提到task_service不仅仅是作为一个网络库的Reactor核心, 它亦可作为日常开发当中多线程及异步编程的利器, 让你不用关心线程切换, 多线程消息投递等细节问题, 通过简单地将请求包装成一个异步方法, 投递到指定的task_service(线程池)中, 就能执行该任务, 在之后的系列文章中我会做详细分析.

Chaos与libevent, boost asio, ACE, ICE等知名库的不同之处

    从开始写chaos时, 我的初衷可能就不是libevent, boost asio那样的通用库, 而是帮助使用者快速搭建一个简单易用的tcp服务, 基于reactor核心写的network模块也是出于这个目的而做的封装. 如果使用libevent或boost asio, 你依然要关心如何去接受一个连接, 去创建启动线程, 去驱动EventLoop, 考虑如何分配线程, 如何管理连接, 而如果使用ACE, ICE, 又会显得比较臃肿庞大, 另一个角度看, ICE是个网络服务解决方案, 而不是单纯的网络库, 而chaos就介于他们之间, 即保持着一定的轻量化, 也希望使用者能够足够易用快速开发, 当然, 这样也必然会失去一些灵活性, 但我个人觉得这对于绝大部分应用都无伤大雅.

性能

    对于部分应用来讲, 虽然网络层不会成为整个服务的瓶颈所在, 但网络库的性能依然至关重要, 我个人认为在本机做吞吐量的测试是一个不错的途径, 而且不用考虑硬件网卡的限制, 我的方法是在同样的机器环境上, 根据不同的应用层缓冲区大小, 连接数, 单线程/多线程 这几个方面来评测.

    具体流程是, 客户端启动N个线程并启动N个TCP连接向服务器发送数据, 服务器接收到完整的数据包之后马上回传相同内容给对端(如同上面的echo server), 一段时间后统计整个过程的吞吐量, 以下是我统计的相关数据:

测试环境信息

服务器型号: HP DL160

CPU: E5504

MEM：

当然, 需要一提的是这份吞吐量测试报告和其他一些网络库的吞吐量测试没有太大的可对比性, 毕竟不同的硬件环境,不同的测试代码给结果带来的差距比我们想象当中的要大.

吞吐量的测试客户端可在test/throughput_client目录中找到完整的代码

服务器代码见echo_server

待续

    之后我会根据个人时间继续推出一些系列的文章和大家分享, 继续讨论chaos的一些设计上遇到的问题, 同时库本身还存在很多问题, 我会继续完善下去.

    更多信息请关注:

    新浪微博         -   http://weibo.com/crazyprogramerlyj