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

原文地址：http://www.cppthinker.com/?p=57