Chaos是一个基于Linux平台, c++开发的reactor模式的网络事件库, 目前仅支持TCP传输协议, 仅在x86_64下编译, 并遵循3-clause BSD开源协议. 在使用上, 可以说它很像boost asio, 可能是由于我对boost asio的接口设计很有爱吧, 而且对于boost asio在异步编程方面的思想, 我个人也比较认同, 但至今我也没有仔细阅读过boost asio的源码, 一是boost的模板化编程在可读性上让我比较折磨, 其二则是不想在对设计先入为主的情况下去开发chaos, 很多事情只有我们自己亲自去思考, 才能有所收获.
进入主题, 关于chaos库源码和所有测试用例和应用服务, 都可在https://github.com/lyjdamzwf/chaos 下载
源码目录结构
chaos – chaos库源码
async_method – 用于异步消息队列的实现, 是最小的task单位, 类似于boost::bind & boost:function
utility – 常用工具类
thread – 对pthread的封装
task_service – 核心模块, 包含了异步消息队列, 网络I/O管理, 以及超时事件， task_service可以作为多线程异步编程强大的工具而不单单作为一个网络层的reactor模块(相当于boost asio的io_service)
log – 日志组件
heart_beat – 基于task_service的通用型元素心跳管理.
network - 基于task_service, 底层I/O multiplexing使用epoll LT模式, 提供了常用的socket行为, 统一对连接进行管理, 并提供了用户空间的读写缓冲区, 可以使开发者快速地搭建一个tcp服务器
test – 一些测试用例, 小到一个工具类的测试, 大到不同类型的服务器程序
简单的TCP Server
要建立一个tcp server, 使用chaos只要简单的三步:
1. 首先我们要先定义一个连接事件回调, 当chaos发现任何连接状态的改变都会回调该函数
2. 连接策略类的定义, 该类告诉chaos对于tcp数据包如何处理
这里需要特别说明一点的是, 对于tcp字节流的处理, chaos底层有默认的机制, 当一个完整的数据包被读取之后, handle_packet就会被调用, 可以看到, 服务在收到完整的数据包之后, 发送了同样的内容给对端.
默认策略的实现就在test_server_echo_conn_t所继承的default_conn_strategy_t中, 该类对所有tcp字节流的处理流程是:
默认策略的包头成员:
如果你希望使用自己的tcp字节流解析策略, 那么可以自己继承chaos::network::connection_t进行实现, 在初始化服务的时候注入自己的策略即可, 具体方式是提供一个你继承自connection_t的类, 然后作为tcp_service_t的模板参数
3. 初始化并启动服务
chaos::network::tcp_service_t类的运行机制是固定一个线程做accept的工作, 而accept成功的连接会分派到各个work线程上进行I/O, work线程的数量可在start时指定.
这样就完成了一个简单的tcp echo server的建立, 以上只是我截取的关键代码片段, 在chaos/test/echo_server目录中有完整的代码可供参考.
如何生成并应用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：
OS: centOS 5.8
当然, 需要一提的是这份吞吐量测试报告和其他一些网络库的吞吐量测试没有太大的可对比性, 毕竟不同的硬件环境, 不同的测试代码给结果带来的差距比我们想象当中的要大.
吞吐量的测试客户端可在test/throughput_client目录中找到完整的代码
服务器代码见echo_server
