Chaos - 開源的c++網絡事件庫
Chaos是一個基于Linux平臺, reactor模式的網絡事件庫, 目前僅支持TCP傳輸協議, 僅在x86_64下編譯, 并遵循3-clause BSD開源協議. 在使用上, 可以說它很像boost asio, 可能是由于我對boost asio的接口設計很有愛吧, 而且對于boost asio在異步編程方面的思想, 我個人也比較認同, 但至今我也沒有仔細閱讀過boost asio的源碼, 一是boost的模板化編程在可讀性上讓我比較折磨, 其二則是不想在對設計先入為主的情況下去開發chaos, 很多事情只有我們自己親自去思考, 才能有所收獲.
這里需要特別說明一點的是, 對于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:
OS: centOS 5.8當然, 需要一提的是這份吞吐量測試報告和其他一些網絡庫的吞吐量測試沒有太大的可對比性, 畢竟不同的硬件環境,不同的測試代碼給結果帶來的差距比我們想象當中的要大.
吞吐量的測試客戶端可在test/throughput_client目錄中找到完整的代碼
服務器代碼見echo_server
待續
之后我會根據個人時間繼續推出一些系列的文章和大家分享, 繼續討論chaos的一些設計上遇到的問題, 同時庫本身還存在很多問題, 我會繼續完善下去.
更多信息請關注:
新浪微博 - http://weibo.com/crazyprogramerlyj
ChinaUnix博客 - http://blog.chinaunix.net/space.php?uid=14617649