作者博客：
http://blog.csdn.net/yahle
大綱：
項目的歷史背景
服務器的設計思路
服務器的技術
服務器的設計
服務器的改進
圖形引擎myhoho及UI庫的設計

客戶端與服務器的集成


網 絡游戲一般采用C\S模式，網絡游戲的設計重點，我認為在于Server端,也就是我們說的服務器。在服務器端的設計，我把服務器按照功能分為2個部分， 一個負責游戲世界的處理，一個服務器服務器與客戶端的通訊。在負責游戲世界的處理的服務器，我又按照功能分為地圖服務器和邏輯服務器。這樣劃分的依據是他 們處理的內容不同進行。當初的設計還考慮到系統的集群功能，可以把游戲的地圖移動處理和游戲的邏輯處理都分別分攤到其它服務器里面去。但是做到最后，發現 這樣的設計也不是太好，主要是因為在處理一些游戲事件的時候需要兩個服務器之間進行協同，這樣勢必要創建一定的網絡游戲消息，在開始制作游戲的時候，因為 需要系統的東西不是很多，所以沒有太注意，到項目的后期，想增加一個功能的時候，就發現在處理船只沉沒的時候，服務器需要傳遞很多同步數據，而且服務器各 自在設置玩家數據的時候，也有很多重復的地方。如果今后還要再加點什么其它功能，那要同步的地方就實在是太多了，所以按照功能把服務器分為2個部分的設計 還是存在缺陷的，如果讓我重新再來，我會選擇單服務器的設計，當然這個服務器還是要和連接服務器進行分離，因為游戲的邏輯處理和與玩家的通訊還是很好分開 的，而且分開的話，也有利于邏輯服務器的設計。







登陸（連接）服務器的設計：



   在網絡游戲里，其中一個很大的難點就是玩家與服務器的通訊，在Windos的服務器架構下，網絡游戲服務器端采用的I/O模型，通常是完成端口。在項目 開始時研究完成端口，感覺很難，根本看不懂，因為它在很多地方與以前寫網絡通訊軟件時用的方法不同。但是當我分析過3個完成端口的程序后，基本了解的它的 使用方法。而且在懂以后，回過頭來看，其它完成端口的概念也不是很復雜，只要能清楚的了解幾個函數的使用方法以及基本的處理框架流程，你就會發現它其實非 常的簡單。



   完成端口的一些需要理解的地方：



1。消息隊列



2。工作線程



3。網絡消息返回結構體







   一般我們在設計服務器端的時候，最關鍵的地方是如何分辯剛剛收到的網絡數據是由那個玩家發送過來的，如果是采用消息事件驅動的話，是可以得到一個 socket的值，然后再用這個值與系統里存在的socket進行比對，這樣就可以得到是那位玩家發送過來的游戲消息。我在還沒有使用完成端口的時候，就 是使用這個方法。這樣的設計有一個缺點就是每次收到數據的時候回浪費很多時間在于確定消息發送者身份上。但是在完成端口的設計里，我們可以采用一個取巧的 方法進行設計。所以，這個問題很輕易的就結局了，而且系統開銷也不是很大，關于完成端口，可以參考一下的文章：



《關于Winsock異步I/O模型中的事件模型》



http://search.csdn.net/Expert/topic/166/166227.xml?temp=.4639093



《手把手教你玩轉SOCKET模型之重疊I/O篇》



http://blog.csdn.net/piggyxp/archive/2004/09/23/114883.aspx



《學習日記]IOCP的學習－－初步理解》



http://www.gameres.com/bbs/showthread.asp?threadid=25898



《用完成端口開發大響應規模的Winsock應用程序》



http://www.xiaozhou.net/ReadNews.asp?NewsID=901



《理解I/O Completion Port》



http://dev.gameres.com/Program/Control/IOCP.htm



幾個關鍵函數的說明：



http://msdn.microsoft.com/library/en-us/fileio/fs/postqueuedcompletionstatus.asp?frame=true



http://msdn.microsoft.com/library/en-us/fileio/fs/createiocompletionport.asp?frame=true



http://msdn.microsoft.com/library/en-us/fileio/fs/getqueuedcompletionstatus.asp?frame=true



http://msdn.microsoft.com/library/en-us/winsock/winsock/wsarecv_2.asp?frame=true







如果你能認真的搞清楚上面的東西，我估計你離理解完成端口就只有一步了。剩下的這一步就是自己編碼實現一個下了。有些時候，看得懂了不一定會實際應用，不實實在在的寫一點程序，驗證一下你的想法，是不會真正搞清楚原理的。







不 過除非你想深入的研究網絡技術，否則只要知道怎么用就可以了，剩下的就是尋找一個合適的別人封裝好的類來使用。這樣可以節省你很多的事件，當然拿來的東西 最好有源代碼，這樣如果發生什么問題，你也好確定是在那個地方出錯，要改或者擴充功能都會方便很多。當然，還要注意人家的版權，最好在引用別人代碼的地方 加一些小小的注解，這樣用不了多少時間，而且對你，對原作者都有好處^_^。







不過在 完成端口上我還是沒有成為拿來主義者，還是自己封裝了完成端口的操作，原因找到的源代碼代碼封裝的接口函數我怎么看怎么覺得別扭，所以最后還是自己封裝了 一個完成端口，有興趣的可以去看我的源代碼，里面有很詳細的注解。而且就我看來，要拿我封裝的完成端口類使用起來還是很簡單的。使用的時候，只要繼承我的 CIOCP，然后，根據需要覆蓋3個虛函數（OnAccept，OnRead，OnClose）就可以了，最多是在連接函數里，需要用一個函數去設置一下 完成端口信息。當然，我封裝的類稍微簡單了一些，如果要拿來響應大規模連接，還是存在很多的問題，但是如果只是針對少量連接，還是可以應付的。







對 于客戶端的I/O模型，我就沒有那么用心的去尋找什么好的解決方案，采用了一個最簡單的，最原始的阻塞線程的方法做。原理很簡單：創建一個sockt，把 socket設置為阻塞，連接服務器成功后，啟動一個線程，在線程里面用recv()等待服務器發過來的消息。在我的代碼里，也是把阻塞線程的方法封裝成 一個類，在使用的時候，先繼承TClientSocket，然后覆蓋（重載）里面的OnRead()函數，并在里面寫入一些處理收到數據后的操作代碼。在 用的時候，只要connect成功，系統就會自動啟動一個接收線程，一旦有數據就觸發剛才覆蓋的OnRead函數。這個類我也不是完全直接寫的，在里面使 用了別人的一些代碼，主要是讓每個類都能把線程封裝起來，這樣在創建不同的類的實體的時候，每個類的實體自己都會有一個單獨的數據接收線程。



當 然除了阻塞線程的方法，比較常用的還有就是用消息事件的方法收取數據了。我剛開始的時候，也是采用這個方法（以前用過^_^），但是后來發現不太好封裝， 最后采用阻塞線程的方法，這樣做還有一個好處可以讓我的代碼看起來更加舒服一些。不過就我分析《航海世紀》客戶端采用的是消息事件的I/O模型。其它的網 絡游戲就不太清楚了，我想也應該是采用消息事件方式的吧。。



   我記得在gameres上看到過某人寫的一篇關于完成端口的筆記，他在篇末結束的時候，提出一個思考題：我們在學習完成端口的時候，都知道它是用于server端的操作，而且很多文章也是這樣寫的，但是不知道有沒有考慮過，用完成端口做客戶端來使用？



   其實這個問題很好回答，答案是OK。拿IOCP做客戶端也是可行的，就以封裝的IOCP為例，只要在繼承原來的CIOCP類的基礎上，再寫一個Connect（char * ip, int port）的函數，就可以實現客戶端的要求了。
bool CIOCPClient::Connect(char *ip, int port) {        //  連接服務器    if (!bInit)        if (!Init())            return false;    //  初始化連接socket    SOCKET m_socket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);    if (m_socket == SOCKET_ERROR)        return false;    // 填寫服務器地址信息    sockaddr_in ClientAddr;    ClientAddr.sin_family = AF_INET;    ClientAddr.sin_port = htons(port);        ClientAddr.sin_addr.s_addr = inet_addr(ip);    // 綁定監聽端口    bind(m_socket, (SOCKADDR *)&ClientAddr, sizeof(ClientAddr));    if (connect(m_socket, (SOCKADDR *)&ClientAddr, sizeof(ClientAddr)) == SOCKET_ERROR)        return false;    this->m_workThread = true;    g_hwThread = CreateThread(NULL, 0, WorkThread, (LPVOID)this, 0, &m_wthreadID);  //  創建工作線程，用來處理完成端口消息的    this->SetIoCompletionPort(m_socket, NULL);  //  設置完成端口監聽的socket    return true; }
前面一段是用來連接服務器，所有的客戶端程序都是要這樣做的，當連接成功后，m_socket就是我們想要的用于與服務器 端通訊的socket，然后，我們啟動工作線程，并使用SetIoCompletionPort來設置完成端口監聽的socket。只要在原來的基礎上增 加一個函數，就可以把用于服務器的ICOP變成用于客戶端的IOCP。



   在收到網絡數據以后，下一步就是根據需要，把收到的網絡數據包轉變為游戲消息數據包。在轉換之前，首先是要從收到的網絡數據里面提取出有效的消息。這里 為什么說是要提取有效部分？其主要原因是，我們創建的游戲消息數據，在進行網絡傳輸的時候，不是以消息的長度來傳的，而是根據系統在接收到發送數據請求的 時候，根據實際情況來發送的。例如我這里有一條很長的游戲消息，有3k，但是系統一次只能發送1k的數據，所以，我們的游戲消息，只能把我們的游戲消息分 為3個包，分3次發送，這樣在我們接收消息的時候，就會觸發3次OnRead，而這3次OnRead收到的數據都不是一次完整的游戲消息。所以，我們在收 到網絡數據后，要先和上一次收到的網絡數據進行合并，然后再在里面提取出有效的游戲消息，并在提取后，把已經提取的部分刪除。我在這里把這一步操作封裝到 一個類里CBuftoMsg。這里順便說明一下：一條游戲消息的網絡數據包是以0x00EEEE(16進制)為結束標記（《航海世紀》的做法）。
struct TMessage {    char * p;       //  消息頭所在的位置    long len;       //  整個消息的長度 }; class CBuftoMsg { protected:    char msgbuf[BUF_LEN];      char * buf_end;    char * buf_begin;    int buf_len; public:    CBuftoMsg(void);    TMessage getMessage(void);    void cleanup_buf(void);    bool AddMsgBuf(const char *, int);    int tag; }; CBuftoMsg::CBuftoMsg(void) {    buf_begin = msgbuf;    buf_end = msgbuf;    buf_len = 0; } TMessage CBuftoMsg::getMessage() {    char * p    = buf_begin;    TMessage result;    result.len  = 0;    result.p    = NULL;    while(p <= buf_begin + buf_len - 2)    {        if ( *p == 0x00)        {            const static char ce = 0xEE;            if (*(p + 1) == ce)                if(*(p + 2) == ce)                {                    //  每條消息都是以 00 EE EE 為結束標志                    result.p    = buf_begin;                    result.len  = p - buf_begin + 3;                    buf_begin   =  p + 3;                    buf_end     = buf_begin + buf_len;                    buf_len -= result.len;                    break;                }        }        p++;    }    return result; } void CBuftoMsg::cleanup_buf() {    if (buf_len < BUF_LEN)    {        if (buf_len == 0)        {            buf_begin   = msgbuf;            buf_end     = msgbuf;        }        else        {            memmove(msgbuf, buf_end - buf_len, buf_len);            buf_begin = msgbuf;            buf_end = buf_end - buf_len;        }    }    else    {        //  加入緩沖區的數據過多，要拋棄原來的內容        buf_begin   = msgbuf;        buf_end     = msgbuf;        buf_len     = 0;    } } bool CBuftoMsg::AddMsgBuf(const char * buf, int len) {    if (len < 1)        return false;    bool result = true;    buf_len += len;    if (buf_len >= BUF_LEN)     //  如果緩沖區裝滿了則直接把原來的緩沖區清空再重新復制數據    {        this->cleanup_buf();            result = false;    }    memcpy(buf_begin, buf, len);    return result; }

我在這里把 CBuftoMsg 的代碼貼出來，主要是因為，我在寫本文的時候，發現一個驚天動地的bug，有興趣的讀者可以自己去找一下。不過一開始寫代碼的時候，還不是這樣的，當初的 代碼bug比這個還要多，問題還要嚴重，嚴重到經常讓服務器程序莫名其妙的崩潰，而且這個問題，一直到5月份，系統在進行集成測試的時候才發現并解決（還 沒有徹底解決，至少目前我還發現了bug，），以前一直都沒有怎么注意到這個問題，而且我們還把因為這個bug造成的問題，歸結到線程的互斥上去^_^!







我的登陸服務器，除了基本的處理網絡數據包以外，還負責玩家系統的登陸驗證，這部分東西不是很復雜，在我的程序里，只是簡單的從ini文件里讀取玩家的信息而已，有興趣的自己去看我的代碼（不過這部分遠還沒有真正的完善，存在很多問題）。







除 了登陸驗證以外，在登陸程序還負責進行消息轉發，就是把客戶端的消息分別發送到不同的服務器。如果當初設計的是一個邏輯服務器，這個功能就可以簡單很多， 只要發送到一個服務器里就可以了。現在的要發到2個服務器，所以還需要對收到的游戲消息進行分類。為了方便，我對原來定義消息的ID進行了分類，所以，在 GameMessageID.h文件里定義的游戲消息對應的ID編號不是順序編排的。不過也因為這樣，在現在看來，這樣的設計，有一些不太好。在整個系統 里，存在有4個主體，他們之間互相發送，就用了12組的數據，為了方便計算，我把一個變量的范圍分為16個不同的區域，這樣每個區域只有16個值可以用 （我這里是用char類型256/16=16）。在加上用另外一個變量表示邏輯上上的分類（目前按照功能分了12組，有登陸、貿易、銀行、船廠等）這樣對 于貿易這個類型的游戲消息，從客戶端發送到邏輯服務器上，只能有16中可能性，如果要發送更多消息，可能要增加另外一個邏輯分類：貿易2^_^!當初這樣 的設計只是想簡化一下系統的處理過程，不過卻造成了系統的擴充困難，要解決也不是沒有辦法，把類型分類的變量由char類型，改為int類型，這樣對一個 變量分區，在范圍上會款很多，而且不會造成邏輯分類上的困擾，但是，這樣存在一個弊端就是就是每條網絡消息數據包的長度增加了一點點。不要小看這一個字節 的變量，現在設計的一條游戲消息頭的長度是10個字節，如果把char改為int，無形中就增加了3個字節，在和原來的比較，這樣每條消息在消息頭部分， 就多出23％，也就是我們100M的網絡現在只能利用77％而已。



   ^_^呵呵看出什么問題沒有？



   沒有，那我告訴你，有一個概念被偷換了，消息頭的數據不等于整條游戲的消息數據，所以，消息頭部分雖然多出了23％，但是整條游戲消息并不會增加這么 多，最多增加17％，最少應該不會操作5％。平均起來，應該在10％左右（游戲消息里，很多消息的實際部分可能就一個int變量而已）。不過，就算是 10％，也占用了帶寬。



   ^_^呵呵還看出什么問題沒有？



   ^_^先去讀一下我的代碼，再回頭看看，上面的論述還有什么問題。



   實際上，每條游戲消息由：消息頭、消息實體、結束標記組成，其中固定的是消息頭和結束標記，所以，實際上一條實際上游戲消息的數據包，最多比原來的多15％，平均起來，應該是8％～10％的增量而異。



   好了，不在這個計算細節上扣太多精力了。要解決這個問題，要么是增加網絡數據的發送量，要么，就是調整游戲結構，例如，把兩個功能服務器合并為一個服務 器，這樣服務器的對象實體就由原來的4個分為3個，兩兩間的通訊，就由原來的12路縮減為6路，只要分8個區域就ok了。這樣每個邏輯分類就有32條游戲 消息可以使用。當然，如果進一步合并服務器，把服務器端都合并到一個程序，那就不用分類了^_^!

   在登陸服務器目錄下，還有一組mynet.h/mynet.cpp的文件，是我當初為服務器端設計的函數，封裝的是消息事件網絡響應模型。只不過封裝得 不是怎么好，被拋棄不用了，有興趣的可以去看看，反正我是不推薦看的。只不過是在這里說明一下整個工程目錄的結構而已。