開源跨平臺網絡庫(lxnet)

暫且，只偏向於遊戲服務器。

先後半年多，從一個雛形到如今基本上功可以用。
性能上也通過仔細雕琢，固然確定有更好的優化方案，暫時未想到，若你有好的建議，並願意探討，請聯繫我，謝謝！。

項目地址： https://github.com/lcinx/lxnet

它是什麼：

是一個tcp的非通用網絡庫，在考慮空間佔用、性能、功能性的基礎上，結合項目需求而產生的。

壓縮，加密在網絡線程裏執行。

適用平臺：

Windows、Linux、Mac OS X

適用場合、範圍:

適合於這樣的應用：

須要在某一個特定的線程中處理若干個鏈接的網絡消息包，在此線程（但不限於）中進行回饋數據包。 --- 好比 邏輯處理爲單線程的遊戲服務器。

反例：web服務器這樣的echo服務(其可多線程邏輯 --- 故... )， 其爲收到請求，返回，相似這樣的應用不推薦使用。

特別注意的：

a). 對於一個鏈接的實體---socketer對象，getmsg方法同時只能在一個線程中調用，源於其緩衝實現。一樣，sendmsg也只能同時在一個線程中調用，不然，，，

b). 當accept一個鏈接後，若未投遞接收數據操做(調用 checkrecv相似的方法，不用擔憂重複投遞操做問題。)，則不會收到消息包的。

c). sendmsg僅僅是把數據壓入緩衝中而已，若未投遞發送數據操做(調用 checksend相似的方法不用擔憂重複投遞操做問題。)，則不會真正的發送。

d). 關於界限(遇過緩衝撐爆嗎？)。 對於服務器而言，防止惡意等比較重要， 此處提供接收界限 --- 接收到的數據達到界限時，不在進行接收，若下次可接收時，也只有用戶去投遞接收。發送的界限 --- 若客戶端一直不接收，而服務器的「推」致使給客戶端發送不少數據時，達到界限時，會斷開此鏈接。

e). 關於加密。提供的默認加密/解密就是簡單的異或運算而已。 支持對某個鏈接設置自定加密/解密函數，可附加加密/解密邏輯數據，來實現相似wow那樣的加密。 可參考arcemu源碼。

對某個鏈接開啓加密或解密時， 切記對端開啓相反的。

f). 關於壓縮。採用quicklz壓縮庫(關於它的性能測試能夠參考其官方)。 理想的使用情況爲 --- 致使彙集壓縮。

如：

一幀結束時在調用checksend相似方法(不瞭解什麼是幀的，能夠理解爲程序中的那個死循環一次爲一幀，暫且如此理解)。 此時爲最優彙集壓縮， 若每次sendmsg後，調用下checksend，那麼。。。彙集壓縮的優點就不會那麼明顯的(也可認爲壓縮比沒那麼高，對於較少的數據，壓縮比始終是 不合算的，彙集壓縮可減小壓縮庫api調用次數，從而下降cpu開銷，並能夠提升壓縮比 --- 相對於壓縮較少的數據)。

若開啓壓縮時，請注意net_init 中的buf參數，不論用的smallbuf仍是bigbuf， 客戶端的對應的要和服務器的相匹配。 想象下，解壓縮的時候，用於解壓縮的緩衝容納不下？(此緩衝大小外部無接口設置，它大小是參考bigbuf, smallbuf中的較大值，再加上一個預留值)。

啓用壓縮，也切記配對。

g). bigbuf與smallbuf， 不表明bigbuf必定要大於smallbuf， 無此檢測。

對於服務器間通信，buf大點好，能夠設置256KB， 對於客戶端與服務器間，一個buf 8K 或 16K 或 32K（根據數據量來衡量）， 粒度越小，分配頻率越高，開銷越大。

h). buf管理採用塊鏈，無任何空間浪費。

如何擴展消息包結構:

繼承 msgbase.h 文件中的 Msg 便可。

說明(續)： 這樣一種狀況下的用法:

A線程處理邏輯，B線程處理 數據庫操做，數據庫操做完成時，須要經過網絡發送出去；爲了不在不一樣線程中調用sendmsg(A線程可能還發送ping消息。)， 一個可行的方案是：使用任務隊列，A線程裏壓入任務，B線程獲取任務，數據庫操做完成後，再把任務結果壓入隊列；在A線程中處理任務 --- 也就是發送數據。