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