發布一個開源的c++網路事件庫【轉載Zark@cppthinker.com】

Chaos是一個基於Linux平台, 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:functionutility                                   - 常用工具類thread                                  - 對pthread的封裝task_service                          - 核心模組, 包含了非同步訊息佇列, 網路I/O管理, 以及逾時事件，ask_service可以作為多線程非同步編程強大的工具而不單單作為一個網路層的reactor模組(相當於boost asio的io_service)log                                       - 日誌組件heart_beat                            - 基於task_service的通用型元素心跳管理.network                                - 基於task_service, 對tcp server進行了封裝, 底層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

 

待續

    之後我會根據個人時間繼續推出一些系列的文章和大家分享, 繼續討論chaos的一些設計上遇到的問題, 同時庫本身還存在很多問題, 我會繼續完善下去.

 

    更多資訊請關注:

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

    ChinaUnix部落格 -    http://blog.chinaunix.net/space.php?uid=14617649