戰(zhàn)魂小筑

主要修改：

更新了文檔（這是必須的）

新的無符號整數(shù)C API

位處理函數(shù)重命名

更好及更快的支持雙精度浮點數(shù)轉(zhuǎn)換為整型

原文在此

可以看到，我在年初發(fā)文指出的lua數(shù)字處理方面的bug已經(jīng)得到很好的解決，不過這種解決方法只是添加了api而已，看來還是沒有松鼠腳本處理的徹底，原文在此

QQ替代方案：

Gtalk http://www.google.com/talk/     SSL加密聊天，免費永久漫游保存聊天記錄

飛信：http://feixin.10086.cn/download/pcclient/  短信,PC溝通更好

QQMail替代方案

GMail https://mail.google.com/mail/?tab=ym  SSL加密，與Gtalk互動，容量不斷增長

瀏覽器+瀏覽網(wǎng)頁替代方案（當(dāng)然，我不可能用QQ瀏覽器的）

Chrome+Google Reader，都支持手機(jī)版互動，訂閱推送，免費翻墻閱讀

Google Doc很長時間無法使用，火了，GFW又把地址屏蔽了

修改hosts文件：

209.85.225.101 docs.google.com

74.125.127.100 writely.google.com

74.125.127.139 spreadsheets.google.com

209.85.147.109 pop.gmail.com

209.85.147.109 smtp.gmail.com

66.102.7.19 mail.google.com

209.85.225.101 docs.google.com

209.85.225.102 groups.google.com

74.125.127.100 services.google.com

74.125.127.100 sites.google.com

209.85.225.104 reader.google.com

74.125.127.101 calendar.google.com

今天找到了貴論壇，發(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è)計。一個線程池負(fù)責(zé)處理io，這個實際上就是一組boost::asio::io_service::run，每個boost::asio::io_service下有一組私有線程，負(fù)責(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），這樣在多處理器（或者多核處理器）下效率可以達(dá)到最高；
#2 complete handler設(shè)計。另一個線程池負(fù)責(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以下的值拷貝的時間損耗都遠(yuǎn)遠(yuǎn)小于對應(yīng)的動態(tài)內(nèi)存申請的時間；另外使用值拷貝也有線程安全的考慮）；
#3 封包的設(shè)計。head+body，head中有固定4字節(jié)的body長度信息（int32）和4字節(jié)的封包類型信息（int32），如果愿意，可以修改代碼進(jìn)行擴(kuò)展（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，用戶的線程池負(fù)責(zé)處理、消費）
#5 session的設(shè)計。一個session就是一個成功連接進(jìn)來的客戶端socket代理，出于線程安全和效率的考慮，session的存儲容器不使用任何stl和boost的容器，而是使用——C的數(shù)組（當(dāng)然不是靜態(tài)數(shù)組，而是：new char[n]這樣的），來實現(xiàn)。而且是二維數(shù)組，這樣配合對象池（指與先分配好一組“空”的session），我們無需任何互斥變量就能夠毫無阻礙的訪問和修改數(shù)組中的每個元素（session），并發(fā)性能達(dá)到最大。至于二維數(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進(jìn)來，或者程序退出等）；
#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)有新連接進(jìn)來的socket使用了自己，則將自己的valid_code +1，當(dāng)加到最大值的時候（例如剛才舉例的10000000等），自動變?yōu)樽钚≈担ɡ鐒偛诺?等）。每個session的valid_code在引擎的初始化階段是隨機(jī)生成的（在事先指定好的數(shù)據(jù)段中隨機(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)部自動進(jìn)行了處理，無須用戶單獨設(shè)置；跨平臺以及不同編譯器的預(yù)編譯設(shè)置，以及不同cpu的針對處理（x86，powerpc等）
目前的不足之處：
#1 并未開發(fā)完全。udp沒有實現(xiàn)封裝，當(dāng)然boost::asio完全支持。logger目前只支持printf功能，對于寫file和傳遞到專門的log服務(wù)器方面只留下了接口；封包加密以及安全方面是一個空白，目前的版本并未添加。
#2 面向底層，并不提供高層功能，所以很多開發(fā)都需要自己進(jìn)行；（對，這并不是一個“網(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，跨平臺、性能和擴(kuò)展性都很優(yōu)秀，而且被C++標(biāo)準(zhǔn)委員會所支持，很被看好。
作者：Nouness

我習(xí)慣把移動硬盤的盤符設(shè)為比較靠后的字母，這樣每次看盤符就知道是哪個硬盤在用

比如，500G 為V盤， 80G 為W盤

今天突然想到，把2G的U盤，設(shè)為U盤符，嘿嘿，挺方便的

“靠到U盤，就是那個U：盤，不是硬盤”

測試環(huán)境：Visual Studio 2008 SP1

測試對象：RTTI的dynamic_cast和自己實現(xiàn)的RTTI系統(tǒng)，代碼如下

        template<typename TClass>

        TClass* Cast( )

        {

            return IsKindOf( TClass::StaticGetClassInfo() ) ? (TClass*)this:null;

        }

    bool RTTIObject::IsKindOf( RTTIClass* ClassInfo )

    {

        RTTIClass* ThisClass = GetRTTIClass();

        if ( ThisClass == null )

            return false;

        return ThisClass->IsKindOf( ClassInfo );

    }

    bool RTTIClass::IsKindOf( RTTIClass* ClassInfo )

    {

        RTTIClass* ThisClass = this;

        while ( ThisClass != null )

        {

            if ( ClassInfo == ThisClass )

                return true;

            ThisClass = ThisClass->mParentClass;

        }

        return false;

    }

測試代碼：

class ClassA : public RTTIObject

{

public:

DECLARE_RTTI_CLASS( ClassA )

int a;

private:

};

IMPLEMENT_RTTIROOT( ClassA )

class ClassB: public ClassA

{

    DECLARE_RTTI_CLASS( ClassB )

public:

int b;

private:

};

IMPLEMENT_RTTI_CLASS( ClassB, ClassA )

class ClassC : public ClassB

{

    DECLARE_RTTI_CLASS( ClassC )

public:

int c;

private:

};

IMPLEMENT_RTTI_CLASS( ClassC, ClassB )

class ClassD: public ClassA

{

    DECLARE_RTTI_CLASS( ClassD )

public:

int d;

private:

};

    ClassC c;

    ClassD d;

    ClassA* fakeC = &c;

    ClassA* fakeD = &d;

    const int TestTimes = 10000;

    float t1 = TimeSource::GetAppTime();

    for ( int i = 0;i<TestTimes;i++)

    {

        ClassC* realC = dynamic_cast<ClassC*>(fakeC);

        ClassD* realD = dynamic_cast<ClassD*>(fakeD);

    }

    float t2 = TimeSource::GetAppTime() - t1;

    for ( int i = 0;i<TestTimes;i++)

    {

        ClassC* realC = fakeC->Cast<ClassC>( );

        ClassD* realD = fakeD->Cast<ClassD>( );

    }

    float t3 = TimeSource::GetAppTime() - t2;

    SimpleLog log;

    log.Debug(L"%f  %f", t2, t3);

可以看得出來，沒有優(yōu)化過的Cast代碼性能極差，但是優(yōu)化過的Cast性能超越了系統(tǒng)的dynamic_cast,跟蹤匯編發(fā)現(xiàn)系統(tǒng)有做個一些異常及bad_cast的處理

建議：可以做一個宏，在不支持RTTI的編譯器及平臺下使用自己的Cast

Asio的架構(gòu)：Boost.Asio 設(shè)計索引

概念性了解API：boost::asio中的同步與異步

Asio的Buffer: buffer幾種用法,這些Buffer都只是引用外部的內(nèi)存數(shù)據(jù)，如果需要拷貝和分配，記得使用boost::pool，這里還有一篇處理拷貝Buffer的文章

例子解析: Boost.asio的簡單使用(timer,thread,io_service類)

如果照著例子弄出的第一個服務(wù)器無法收到客戶端消息，試試這個asio::async_read與socket的async_read_some的區(qū)別

這里是另外一個區(qū)別：boost.asio庫學(xué)習(xí)筆記—— receive和read的區(qū)別：

從服務(wù)器連接過來的客戶端的地址：

std::string endpoint = socket.remote_endpoint( ).address( ).to_string();

以下是對這篇文章的翻譯:

asio chat_client.cpp中的一些問題

1. 有多少個線程在運行2個，還是3個？

>一般來說，依賴于運行的平臺，從程序的角度來說是2個，包括：

*主線程，用于處理用戶的輸入輸出

*io_service.run()線程，用于處理chat_client對象中的所有行為(action)

還有，async_write會創(chuàng)建一個線程或者其他的一些東西么？

>不會.

2. 有關(guān)1的問題，為什么write函數(shù)使用post直接調(diào)用？什么不調(diào)用async_write？既然調(diào)用了post，你只是將其放到一個隊列里在同一線程處理，為什么之后還要從其他線程調(diào)用async_write？

chat_client的成員對象不是線程安全的（故意？），因此要同步處理這些成員。如果直接從主線程調(diào)用async_write不是線程安全的，因為此時可能有后臺線程正在訪問socket。

在這個例子中，所有的類成員都調(diào)用io_services.post()以保證在一個線程里訪問，達(dá)到線程安全。io_services保證任何使用io_services.post()（或io_servies.dispatch())傳入的句柄只會在io_serive.run()線程被調(diào)用。而且這個例子中只有一個線程調(diào)用io_service.run()，所以chat_client的成員變量也只會在一個線程中被訪問。

4. 如果我想發(fā)送一個連接事件到主線程，怎樣做？用io_service::post？能從主線程獲取io_services？

在這個例子里是很困難的，因為主線程正在阻塞等待用戶信息。不過如果你想將事件在線程間傳遞，確實可以為每個線程配備一個io_services。

5. 為什么在main函數(shù)的最后調(diào)用了t.join()，能用io_service.run()代替么？

不行，請參考問題2的解答，那樣的話，線程安全將無法保證

6. 按照問題1的解答，如果有3個線程在運行（也就是，async_write被放到另外一個線程），那么哪個位置創(chuàng)建這個線程比較好？

因為主線程需要阻塞等待用戶信息，因此io_service::run是唯一需要的。如果你的程序不需要這樣做，那么就不需要其他線程，也就只需要簡單的調(diào)用io_service::run()就可以了，這也是大多數(shù)例子這樣做的原因

有關(guān)線程安全的問題

1. 對于asio對象，能從2個不同線程調(diào)用一個共享對象的不同成員么？

不能

那么其意義就是從2個不同線程訪問共享對象不是線程安全的？

是的

只有被標(biāo)記為 “共享對象：安全”的對象才能從不同線程同時訪問，io_service就是這樣的對象

2. 同樣是線程安全的問題，對于basic_deadline_timer::cancel()我需要用io_service.post(boost::bind(&deadline_timer::cancel, &myTimer))方法封裝調(diào)用么？

是的，直接調(diào)用cancel()也不是線程安全的

最好的解決方法就是使用io_service::post()將所有的操作都放在一個線程

3. asio有很多成員函數(shù)，我怎么知道哪些能安全的調(diào)用？

一般情況下，你應(yīng)該認(rèn)為沒有任何一個函數(shù)是安全的，以下是通用的io線程安全判斷用例：

write+write:不安全

read+write:不安全

read+read:安全

asio對象已經(jīng)符合這種需求

這里有一篇介紹io_service眾多區(qū)別及包處理，拆包等的技術(shù)

下載Boost1.44

解壓后運行bootstrap，編譯bjam

在命令行boost目錄中里輸入

bjam –with-system --with-regex --with-date_time --with-thread --with-seri
alization --toolset=msvc-9.0

這里使用的vc2008，其他版本請自行調(diào)整

之前試過網(wǎng)上其他教程，有這么寫的

bjam --without-python --toolset=msvc-9.0 --with-thread --with-date_time --with-regex -
-with-serialization

結(jié)果報錯error: both --with-<library> and --without-<library> specified

所以將without去掉，只寫with就可以正常編譯

使用時，包含boost_1_44_0\目錄，lib在boost_1_44_0\stage\lib即可

D3D9下的獲得RenderTarget有2種方法

1. 使用D3DXCreateTexture或者Device->CreateTexture 創(chuàng)建紋理

    調(diào)用Device->GetSurfaceLevel(0, &SurfacePtr );獲得Surface指針

   將Surface指針使用Device->SetRenderTarget設(shè)置上去即可開始繪制

   注意：D3DXCreateTexture創(chuàng)建的是2的n次冪的紋理，而Device->CreateTexture 創(chuàng)建的則可以是任意大小的紋理

   這種方法創(chuàng)建的Texture與Surface是一一對應(yīng)的，由D3D底層自動做了Resolve的過程

   不能使用MultiSample

2. 使用Device->CreateRenderTarget()創(chuàng)建一個Surface，用Surface直接設(shè)置為RenderTarget

  可以開啟Lockable選項，但是效率會非常低

  可以使用MultiSample

   由于沒有Texture的關(guān)聯(lián)，這種方法繪制速度理論上會快一些

可以使用Device->StretchRect來將Surface直接拷貝到后備緩沖或者另外一個Surface。不過在DX8和某些DX9的驅(qū)動上有一定兼容性問題，具體請參考SDK

參考：

Render to Surface 

   http://www.borgsoft.de/renderToSurface.html

渲染到紋理(Render To Texture, RTT)詳解

   http://www.opengpu.org/bbs/viewthread.php?tid=445

記得2008年時看過360開發(fā)機(jī)的XDK中的D3D中比PC版的多一個ResolveRenderTargetXX之類的函數(shù)，由于一直沒有用到，沒有理會。最近在整合引擎的的RenderTarget中，無意間搜到Console平臺的Resolve的概念：

繪制完RT后，需要調(diào)用Resolve，將RT上的繪制結(jié)果復(fù)制到你的紋理之上。這個步驟是游戲機(jī)特有的，360的RT是只寫的，PC是不需要這個步驟。