拼包函數及網絡封包的異常處理(含代碼) 收藏
本文作者：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上留言提出。

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/clever101/archive/2008/10/12/3061679.aspx