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互動,容量不斷增長
瀏覽器+瀏覽網頁替代方案(當然,我不可能用QQ瀏覽器的)
Chrome+Google Reader,都支持手機版互動,訂閱推送,免費翻墻閱讀
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
今天找到了貴論壇,發現壇主的很多想法和本人不謀而合,本人近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
我習慣把移動硬盤的盤符設為比較靠后的字母,這樣每次看盤符就知道是哪個硬盤在用
比如,500G 為V盤, 80G 為W盤
今天突然想到,把2G的U盤,設為U盤符,嘿嘿,挺方便的
“靠到U盤,就是那個U:盤,不是硬盤”
測試環境:Visual Studio 2008 SP1
測試對象:RTTI的dynamic_cast和自己實現的RTTI系統,代碼如下
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);
10000次,單位:毫秒 | dynamic_cast | Cast |
Debug | 1.468590 | 5.173067 |
Release | 1.025950 | 0.702404 |
可以看得出來,沒有優化過的Cast代碼性能極差,但是優化過的Cast性能超越了系統的dynamic_cast,跟蹤匯編發現系統有做個一些異常及bad_cast的處理
建議:可以做一個宏,在不支持RTTI的編譯器及平臺下使用自己的Cast
Asio的架構:Boost.Asio 設計索引
概念性了解API:boost::asio中的同步與異步
Asio的Buffer: buffer幾種用法,這些Buffer都只是引用外部的內存數據,如果需要拷貝和分配,記得使用boost::pool,這里還有一篇處理拷貝Buffer的文章
例子解析: Boost.asio的簡單使用(timer,thread,io_service類)
如果照著例子弄出的第一個服務器無法收到客戶端消息,試試這個asio::async_read與socket的async_read_some的區別
這里是另外一個區別:boost.asio庫學習筆記—— receive和read的區別:
從服務器連接過來的客戶端的地址:
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會創建一個線程或者其他的一些東西么?
>不會.
2. 有關1的問題,為什么write函數使用post直接調用?什么不調用async_write?既然調用了post,你只是將其放到一個隊列里在同一線程處理,為什么之后還要從其他線程調用async_write?
chat_client的成員對象不是線程安全的(故意?),因此要同步處理這些成員。如果直接從主線程調用async_write不是線程安全的,因為此時可能有后臺線程正在訪問socket。
在這個例子中,所有的類成員都調用io_services.post()以保證在一個線程里訪問,達到線程安全。io_services保證任何使用io_services.post()(或io_servies.dispatch())傳入的句柄只會在io_serive.run()線程被調用。而且這個例子中只有一個線程調用io_service.run(),所以chat_client的成員變量也只會在一個線程中被訪問。
4. 如果我想發送一個連接事件到主線程,怎樣做?用io_service::post?能從主線程獲取io_services?
在這個例子里是很困難的,因為主線程正在阻塞等待用戶信息。不過如果你想將事件在線程間傳遞,確實可以為每個線程配備一個io_services。
5. 為什么在main函數的最后調用了t.join(),能用io_service.run()代替么?
不行,請參考問題2的解答,那樣的話,線程安全將無法保證
6. 按照問題1的解答,如果有3個線程在運行(也就是,async_write被放到另外一個線程),那么哪個位置創建這個線程比較好?
因為主線程需要阻塞等待用戶信息,因此io_service::run是唯一需要的。如果你的程序不需要這樣做,那么就不需要其他線程,也就只需要簡單的調用io_service::run()就可以了,這也是大多數例子這樣做的原因
有關線程安全的問題
1. 對于asio對象,能從2個不同線程調用一個共享對象的不同成員么?
不能
那么其意義就是從2個不同線程訪問共享對象不是線程安全的?
是的
只有被標記為 “共享對象:安全”的對象才能從不同線程同時訪問,io_service就是這樣的對象
2. 同樣是線程安全的問題,對于basic_deadline_timer::cancel()我需要用io_service.post(boost::bind(&deadline_timer::cancel, &myTimer))方法封裝調用么?
是的,直接調用cancel()也不是線程安全的
最好的解決方法就是使用io_service::post()將所有的操作都放在一個線程
3. asio有很多成員函數,我怎么知道哪些能安全的調用?
一般情況下,你應該認為沒有任何一個函數是安全的,以下是通用的io線程安全判斷用例:
write+write:不安全
read+write:不安全
read+read:安全
asio對象已經符合這種需求
這里有一篇介紹io_service眾多區別及包處理,拆包等的技術
解壓后運行bootstrap,編譯bjam
在命令行boost目錄中里輸入
bjam –with-system --with-regex --with-date_time --with-thread --with-seri
alization --toolset=msvc-9.0
這里使用的vc2008,其他版本請自行調整
之前試過網上其他教程,有這么寫的
bjam --without-python --toolset=msvc-9.0 --with-thread --with-date_time --with-regex -
-with-serialization
結果報錯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 創建紋理
調用Device->GetSurfaceLevel(0, &SurfacePtr );獲得Surface指針
將Surface指針使用Device->SetRenderTarget設置上去即可開始繪制
注意:D3DXCreateTexture創建的是2的n次冪的紋理,而Device->CreateTexture 創建的則可以是任意大小的紋理
這種方法創建的Texture與Surface是一一對應的,由D3D底層自動做了Resolve的過程
不能使用MultiSample
2. 使用Device->CreateRenderTarget()創建一個Surface,用Surface直接設置為RenderTarget
可以開啟Lockable選項,但是效率會非常低
可以使用MultiSample
由于沒有Texture的關聯,這種方法繪制速度理論上會快一些
可以使用Device->StretchRect來將Surface直接拷貝到后備緩沖或者另外一個Surface。不過在DX8和某些DX9的驅動上有一定兼容性問題,具體請參考SDK
參考:
Render to Surface
http://www.borgsoft.de/renderToSurface.html
渲染到紋理(Render To Texture, RTT)詳解
記得2008年時看過360開發機的XDK中的D3D中比PC版的多一個ResolveRenderTargetXX之類的函數,由于一直沒有用到,沒有理會。最近在整合引擎的的RenderTarget中,無意間搜到Console平臺的Resolve的概念:
繪制完RT后,需要調用Resolve,將RT上的繪制結果復制到你的紋理之上。這個步驟是游戲機特有的,360的RT是只寫的,PC是不需要這個步驟。