本文作者：sodme
本文出處：http://blog.csdn.net/sodme
宣告：本文可以不經作者同意任意轉載、複製、傳播，但任何對本文的引用都請保留作者、出處及本宣告資訊。謝謝！

　　常見的網路伺服器，基本上是7*24小時運轉的，對於網遊來說，至少要求伺服器要能連續工作一週以上的時間並保證不出現伺服器崩潰這樣的災難性事件。事實上，要求一個伺服器在連續的滿負荷運轉下不出任何異常，要求它設計的近乎完美，這幾乎是不太現實的。伺服器本身可以出異常（但要儘可能少得出），但是，伺服器本身應該被設計得足以健壯，“小病小災”打不垮它，這就要求伺服器在異常處理方面要下很多功夫。

　　伺服器的異常處理包括的內容非常廣泛，本文僅就在網路封包方面出現的異常作一討論，希望能對正從事相關工作的朋友有所幫助。

　　關於網路封包方面的異常，總體來說，可以分為兩大類：一是封包格式出現異常；二是封包內容（即封包資料）出現異常。在封包格式的異常處理方面，我們在最底端的網路資料包接收模組便可以加以處理。而對於封包資料內容出現的異常，只有依靠遊戲本身的邏輯去加以判定和檢驗。遊戲邏輯方面的異常處理，是隨每個遊戲的不同而不同的，所以，本文隨後的內容將重點闡述在網路資料包接收模組中的異常處理。

　　為方便以下的討論，先明確兩個概念（這兩個概念是為了敘述方面，筆者自行取的，並無標準可言）：
　　1、邏輯包：指的是在應用層提交的資料包，一個完整的邏輯包可以表示一個確切的邏輯意義。比如登入包，它裡面就可以含有使用者名稱欄位和密碼欄位。儘管它看上去也是一段緩衝區資料，但這個緩衝區裡的各個區間是代表一定的邏輯意義的。
　　2、物理包：指的是使用recv(recvfrom)或wsarecv(wsarecvfrom)從網路底層接收到的資料包，這樣收到的一個數據包，能不能表示一個完整的邏輯意義，要取決於它是通過UDP類的“資料報協議”發的包還是通過TCP類的“流協議”發的包。

　　我們知道，TCP是流協議，“流協議”與“資料報協議”的不同點在於：“資料報協議”中的一個網路包本身就是一個完整的邏輯包，也就是說，在應用層使用sendto傳送了一個邏輯包之後，在接收端通過recvfrom接收到的就是剛才使用sendto傳送的那個邏輯包，這個包不會被分開發送，也不會與其它的包放在一起傳送。但對於TCP而言，TCP會根據網路狀況和neagle演算法，或者將一個邏輯包單獨傳送，或者將一個邏輯包分成若干次傳送，或者會將若干個邏輯包合在一起傳送出去。正因為TCP在邏輯包處理方面的這種粘合性，要求我們在作基於TCP的應用時，一般都要編寫相應的拼包、解包程式碼。

　　因此，基於TCP的上層應用，一般都要定義自己的包格式。TCP的封包定義中，除了具體的資料內容所代表的邏輯意義之外，第一步就是要確定以何種方式表示當前包的開始和結束。通常情況下，表示一個TCP邏輯包的開始和結束有兩種方式：
　　1、以特殊的開始和結束標誌表示，比如FF00表示開始，00FF表示結束。
　　2、直接以包長度來表示。比如可以用第一個位元組表示包總長度，如果覺得這樣的話包比較小，也可以用兩個位元組表示包長度。

　　下面將要給出的程式碼是以第2種方式定義的資料包，包長度以每個封包的前兩個位元組表示。我將結合著程式碼給出相關的解釋和說明。

　　函式中用到的變數說明：

　　CLIENT_BUFFER_SIZE：緩衝區的長度，定義為：Const int CLIENT_BUFFER_SIZE=4096。
　　m_ClientDataBuf：資料整理緩衝區，每次收到的資料，都會先被複制到這個緩衝區的末尾，然後由下面的整理函式對這個緩衝區進行整理。它的定義是：char m_ClientDataBuf[2* CLIENT_BUFFER_SIZE]。
　　m_DataBufByteCount：資料整理緩衝區中當前剩餘的未整理位元組數。
　　GetPacketLen(const char*)：函式，可以根據傳入的緩衝區首址按照應用層協議取出當前邏輯包的長度。
　　GetGamePacket(const char*, int)：函式，可以根據傳入的緩衝區生成相應的遊戲邏輯資料包。
　　AddToExeList(PBaseGamePacket)：函式，將指定的遊戲邏輯資料包加入待處理的遊戲邏輯資料包佇列中，等待邏輯處理執行緒對其進行處理。
　　DATA_POS：指的是除了包長度、包型別等這些標誌型欄位之外，真正的資料包內容的起始位置。

Bool SplitFun(const char* pData,const int &len)
{
    PBaseGamePacket pGamePacket=NULL;
    __int64 startPos=0, prePos=0, i=0;
    int packetLen=0;

 　//先將本次收到的資料複製到整理緩衝區尾部
    startPos = m_DataBufByteCount;  
    memcpy( m_ClientDataBuf+startPos, pData, len );
    m_DataBufByteCount += len;   

    //當整理緩衝區內的位元組數少於DATA_POS位元組時，取不到長度資訊則退出
　//注意：退出時並不置m_DataBufByteCount為0
    if (m_DataBufByteCount < DATA_POS+1)
        return false; 

    //根據正常邏輯，下面的情況不可能出現，為穩妥起見，還是加上
    if (m_DataBufByteCount >  2*CLIENT_BUFFER_SIZE)
    {
        //設定m_DataBufByteCount為0，意味著丟棄緩衝區中的現有資料
        m_DataBufByteCount = 0;

　　//可以考慮開放錯誤格式資料包的處理介面，處理邏輯交給上層
　　//OnPacketError()
        return false;
    }

     //還原起始指標
     startPos = 0;

     //只有當m_ClientDataBuf中的位元組個數大於最小包長度時才能執行此語句
    packetLen = GetPacketLen( pIOCPClient->m_ClientDataBuf );

    //當邏輯層的包長度不合法時，則直接丟棄該包
    if ((packetLen < DATA_POS+1) || (packetLen > 2*CLIENT_BUFFER_SIZE))
    {
        m_DataBufByteCount = 0;

　　//OnPacketError()
        return false;
    }

    //保留整理緩衝區的末尾指標
    __int64 oldlen = m_DataBufByteCount; 

    while ((packetLen <= m_DataBufByteCount) && (m_DataBufByteCount>0))
    {
        //呼叫拼包邏輯，獲取該緩衝區資料對應的資料包
        pGamePacket = GetGamePacket(m_ClientDataBuf+startPos, packetLen); 

        if (pGamePacket!=NULL)
        {
            //將資料包加入執行佇列
            AddToExeList(pGamePacket);
        }

        pGamePacket = NULL;
 
　　//整理緩衝區的剩餘位元組數和新邏輯包的起始位置進行調整
        m_DataBufByteCount -= packetLen;
        startPos += packetLen; 

        //殘留緩衝區的位元組數少於一個正常包大小時，只向前複製該包隨後退出
        if (m_DataBufByteCount < DATA_POS+1)
        {
            for(i=startPos; i<startPos+m_DataBufByteCount; ++i)
                m_ClientDataBuf[i-startPos] = m_ClientDataBuf[i];

            return true;
        }

        packetLen = GetPacketLen(m_ClientDataBuf + startPos );

         //當邏輯層的包長度不合法時，丟棄該包及緩衝區以後的包
        if ((packetLen<DATA_POS+1) || (packetLen>2*CLIENT_BUFFER_SIZE))
        {
            m_DataBufByteCount = 0;

    　　//OnPacketError()
            return false;
        }

         if (startPos+packetLen>=oldlen)
        {
            for(i=startPos; i<startPos+m_DataBufByteCount; ++i)
                m_ClientDataBuf[i-startPos] = m_ClientDataBuf[i];          

            return true;
        }
     }//取所有完整的包

     return true;
}

　　以上便是資料接收模組的處理函式，下面是幾點簡要說明：

　　1、用於拼包整理的緩衝區(m_ClientDataBuf)應該比recv中指定的接收緩衝區(pData)長度(CLIENT_BUFFER_SIZE)要大，通常前者是後者的2倍(2*CLIENT_BUFFER_SIZE)或更大。

　　2、為避免因為剩餘資料前移而導致的額外開銷，建議m_ClientDataBuf使用環形緩衝區實現。

　　3、為了避免出現無法拼裝的包，我們約定每次傳送的邏輯包，其單個邏輯包最大長度不可以超過CLIENT_BUFFER_SIZE的2倍。因為我們的整理緩衝區只有2*CLIENT_BUFFER_SIZE這麼長，更長的資料，我們將無法整理。這就要求在協議的設計上以及最終的傳送函式的處理上要加上這樣的異常處理機制。

　　4、對於資料包過短或過長的包，我們通常的情況是置m_DataBufByteCount為0，即捨棄當前包的處理。如果此處不設定m_DataBufByteCount為0也可，但該客戶端只要發了一次格式錯誤的包，則其後繼發過來的包則也將連帶著產生格式錯誤，如果設定m_DataBufByteCount為0，則可以比較好的避免後繼的包受此包的格式錯誤影響。更好的作法是，在此處開放一個封包格式異常的處理介面(OnPacketError)，由上層邏輯決定對這種異常如何處置。比如上層邏輯可以對封包格式方面出現的異常進行計數，如果錯誤的次數超過一定的值，則可以斷開該客戶端的連線。

　　5、建議不要在recv或wsarecv的函式後，就緊接著作以上的處理。當recv收到一段資料後，生成一個結構體或物件(它主要含有data和len兩個內容，前者是資料緩衝區，後者是資料長度)，將這樣的一個結構體或物件放到一個佇列中由後面的執行緒對其使用SplitFun函式進行整理。這樣，可以最大限度地提高網路資料的接收速度，不至因為資料整理的原因而在此處浪費時間。

　　程式碼中，我已經作了比較詳細的註釋，可以作為拼包函式的參考，程式碼是從偶的應用中提取、修改而來，本身只為演示之用，所以未作除錯，應用時需要你自己去完善。如有疑問，可以我的blog上留言提出。