今天找到了貴論壇，發現壇主的很多想法和本人不謀而合，本人近1年主要精力都致力于開發一個大型多人在線游戲的基本架構和相關的技術模組。而我欣喜的發現我與壇主的研究方向正好相反：我是先從服務器端開始研究入手的，目前服務器端告一段落，正準備開始客戶端的研發，在尋找客戶端引擎的時候碰巧找到了這里。
我看到壇主的這個板塊，了解到Orz正需要一些服務器方面的資料，在此我先奉上個人的服務器端的一些成果，希望能有所幫助。
（一）自己開發的一個基于boost::asio的網絡引擎
首先這個網絡引擎是基于boost::asio的一個封裝，網絡部分功能非常底層，API只有基本的listen、connect、send、kick等（均為異步，目前只實現了TCP協議），而其他方面提供的是基于mysql的db接口和log接口，還有一個自己開發的對象池，用于使用FreeList的概念來事先分配內存，降低運行時期內存的分配時間；
另外就是開發了一個多線程下的數據結構，一個線程安全的map，這個map可以讓無限個線程同時讀和寫（包括添加元素、刪除元素、修改元素）而無需任何因為互斥鎖定帶來的線程等待等開銷。即是說1000個線程和1個線程操作這個map的效率是相同的。
發布形式：win32（64位未測試，但是開發考慮了相關的定制，例如指針和long在64位下從4字節提高到8字節，引擎底層做了數據類型的typedef）下 dll+lib+include；linux（Redhat、CentOS5.x，gcc3.4以上，需要安裝boost1.37和mysql5.0）so+include；source code，yes，of course！
網絡部分的基本結構是這樣的：
#1 io部分設計。一個線程池負責處理io，這個實際上就是一組boost::asio::io_service::run，每個boost::asio::io_service下有一組私有線程，負責處理異步io事件，這里，boost::asio::io_service得數量和其下私有線程的數量是可以根據配置文件自由設置的，如果你了解boost::asio，那么一定知道它推薦一個cpu對應一個boost::asio::io_service對象（或者一個boost::asio::io_service，但是每個boost::asio::io_service下的私有線程對應每個cpu），這樣在多處理器（或者多核處理器）下效率可以達到最高；
#2 complete handler設計。另一個線程池負責處理封裝好的complete handler，即對應io事件的用戶定義的邏輯處理，例如io recv事件，對應一個用戶實現邦定的（使用boost::bind和boost::function）handler來處理當接受到socket消息的時候調用對應的handler（函數、仿函數對象、成員函數等）。#1和#2中的線程池之間使用一組線程安全的隊列來傳遞消息（傳遞使用直接的值拷貝，不使用動態內存，因為動態內存的申請和釋放太消耗時間，即便使用內存池也一樣。1k以下的值拷貝的時間損耗都遠遠小于對應的動態內存申請的時間；另外使用值拷貝也有線程安全的考慮）；
#3 封包的設計。head+body，head中有固定4字節的body長度信息（int32）和4字節的封包類型信息（int32），如果愿意，可以修改代碼進行擴展（packet部分是獨立于引擎的模塊，也是一組dll,lib,include或者so,include），接受和發送由于是tcp，所以按照head中的body長度來控制一個封包的完整性。
#4 多線程模型。boss-worker模型，主要用于廣播消息、查找、和db、log的實現上；生產者、消費者模型，主要用于#1和#2 的兩個線程池之間的事件傳遞（io線程池產生completehandler，用戶的線程池負責處理、消費）
#5 session的設計。一個session就是一個成功連接進來的客戶端socket代理，出于線程安全和效率的考慮，session的存儲容器不使用任何stl和boost的容器，而是使用——C的數組（當然不是靜態數組，而是：new char[n]這樣的），來實現。而且是二維數組，這樣配合對象池（指與先分配好一組“空”的session），我們無需任何互斥變量就能夠毫無阻礙的訪問和修改數組中的每個元素（session），并發性能達到最大。至于二維數組的設計，第二維的值對應io線程池和用戶線程池中的線程數量，即一個線程唯一邦定一組session，這是為了分配session id時候效率和安全的考慮。（例如id 0~9對應一組session，10~19是第二組，而每組id和session都唯一綁定一個線程）
#6 線程之間數據傳遞的設計。線程安全的queue，使用了boost::thread::locks中的mutex、shared_mutex、condition_variable_any等概念，當queue空閑時，使用條件變量等待特定的事件（例如新的元素push進來，或者程序退出等）；
#7 異步下session的唯一性。由于整體是異步的，所以不可避免的會出現當一個session的某個處理還未結束的時候，這個session已經消失了，甚至換了一個新的session（指id的分配），那么這個時候如果沒有任何防范處理，之前的那個未完成的處理很可能會作用到這個新的session上，就不可避免的出現一些錯誤和未知情況，我們如何防范呢？使用valid_code，設計一個64位的無符號整型變量，給每個session按照事先給定的session總量（這個引擎使用預先分配內存方法，所以開始前必須手動指定session的最大數量——通過配置文件），分配一個唯一的數據段（例如1~10000000，10000001~2000000等），每次這個session發現有新連接進來的socket使用了自己，則將自己的valid_code +1，當加到最大值的時候（例如剛才舉例的10000000等），自動變為最小值（例如剛才的1等）。每個session的valid_code在引擎的初始化階段是隨機生成的（在事先指定好的數據段中隨機）。再加上每個session的數據段時唯一的，所以不會產生重復的valid_code，這樣鑒別某個時間段內唯一的session就成了可能；
#8 agent基類的設計。這個其實就是封裝了boost::thread類，即“帶私有線程的類”，主要用于作為一些相對獨立的工作，例如log記錄、db訪問處理、定期ping某個ip等，引擎中的logger和db接口都是繼承自它；
#9 db接口設計。一個數據庫對應一個database對象，每個database對象擁有一個自己私有的線程池，其中線程的數量可以根據配置文件自由設定（例如和mysql的連接數量等，處理query的線程數量等）
#10 一些零碎。BIG_ENDIAN問題，封包內部自動進行了處理，無須用戶單獨設置；跨平臺以及不同編譯器的預編譯設置，以及不同cpu的針對處理（x86，powerpc等）
目前的不足之處：
#1 并未開發完全。udp沒有實現封裝，當然boost::asio完全支持。logger目前只支持printf功能，對于寫file和傳遞到專門的log服務器方面只留下了接口；封包加密以及安全方面是一個空白，目前的版本并未添加。
#2 面向底層，并不提供高層功能，所以很多開發都需要自己進行；（對，這并不是一個“網游引擎”）
#3 性能方面并未經過大量測試，由于本人工作較忙，這些都是業余時間搞得，所以只是初步測了一下連接并發部分：使用某個不知道配置的筆記本測得3秒并發連接1500。再多的并發連接并沒有嘗試過。
PS 由于本人工作較忙，故只能提供源代碼（只提供windows版，便于查看，linux可以直接使用源代碼編譯，gcc3.4以上boost1.37即可），文檔方面一直沒有時間整理，這篇文章都是中午抽空寫的（零零散散修改到現在），所以暫時就寫這么多把。
PS2 提供的源代碼是vs2005sln，只包含source code、配置和工程文件。
PS3 我看到貴論壇在研究RakNet，據我的一個前同事說，他認為RakNet并不好，網絡底層用的是select，而且不是異步，代碼質量不高，建議我不要使用它的網絡層。我感覺RakNet的一些高層功能還是可以參考的，例如安全加密、大廳分流等，至于網絡底層，我建議還是用boost::asio，跨平臺、性能和擴展性都很優秀，而且被C++標準委員會所支持，很被看好。
作者：Nouness