拼包函數(shù)及網(wǎng)絡(luò)封包的異常處理(含代碼) 收藏
本文作者：sodme
本文出處：http://blog.csdn.net/sodme
聲明：本文可以不經(jīng)作者同意任意轉(zhuǎn)載、復(fù)制、傳播，但任何對(duì)本文的引用都請(qǐng)保留作者、出處及本聲明信息。謝謝！

　　常見(jiàn)的網(wǎng)絡(luò)服務(wù)器，基本上是7*24小時(shí)運(yùn)轉(zhuǎn)的，對(duì)于網(wǎng)游來(lái)說(shuō)，至少要求服務(wù)器要能連續(xù)工作一周以上的時(shí)間并保證不出現(xiàn)服務(wù)器崩潰這樣的災(zāi)難性事件。事實(shí)上，要求一個(gè)服務(wù)器在連續(xù)的滿負(fù)荷運(yùn)轉(zhuǎn)下不出任何異常，要求它設(shè)計(jì)的近乎完美，這幾乎是不太現(xiàn)實(shí)的。服務(wù)器本身可以出異常（但要盡可能少得出），但是，服務(wù)器本身應(yīng)該被設(shè)計(jì)得足以健壯，“小病小災(zāi)”打不垮它，這就要求服務(wù)器在異常處理方面要下很多功夫。

　　服務(wù)器的異常處理包括的內(nèi)容非常廣泛，本文僅就在網(wǎng)絡(luò)封包方面出現(xiàn)的異常作一討論，希望能對(duì)正從事相關(guān)工作的朋友有所幫助。

　　關(guān)于網(wǎng)絡(luò)封包方面的異常，總體來(lái)說(shuō)，可以分為兩大類：一是封包格式出現(xiàn)異常；二是封包內(nèi)容（即封包數(shù)據(jù)）出現(xiàn)異常。在封包格式的異常處理方面，我們?cè)谧畹锥说木W(wǎng)絡(luò)數(shù)據(jù)包接收模塊便可以加以處理。而對(duì)于封包數(shù)據(jù)內(nèi)容出現(xiàn)的異常，只有依靠游戲本身的邏輯去加以判定和檢驗(yàn)。游戲邏輯方面的異常處理，是隨每個(gè)游戲的不同而不同的，所以，本文隨后的內(nèi)容將重點(diǎn)闡述在網(wǎng)絡(luò)數(shù)據(jù)包接收模塊中的異常處理。

　　為方便以下的討論，先明確兩個(gè)概念（這兩個(gè)概念是為了敘述方面，筆者自行取的，并無(wú)標(biāo)準(zhǔn)可言）：
　　1、邏輯包：指的是在應(yīng)用層提交的數(shù)據(jù)包，一個(gè)完整的邏輯包可以表示一個(gè)確切的邏輯意義。比如登錄包，它里面就可以含有用戶名字段和密碼字段。盡管它看上去也是一段緩沖區(qū)數(shù)據(jù)，但這個(gè)緩沖區(qū)里的各個(gè)區(qū)間是代表一定的邏輯意義的。
　　2、物理包：指的是使用recv(recvfrom)或wsarecv(wsarecvfrom)從網(wǎng)絡(luò)底層接收到的數(shù)據(jù)包，這樣收到的一個(gè)數(shù)據(jù)包，能不能表示一個(gè)完整的邏輯意義，要取決于它是通過(guò)UDP類的“數(shù)據(jù)報(bào)協(xié)議”發(fā)的包還是通過(guò)TCP類的“流協(xié)議”發(fā)的包。

　　我們知道，TCP是流協(xié)議，“流協(xié)議”與“數(shù)據(jù)報(bào)協(xié)議”的不同點(diǎn)在于：“數(shù)據(jù)報(bào)協(xié)議”中的一個(gè)網(wǎng)絡(luò)包本身就是一個(gè)完整的邏輯包，也就是說(shuō)，在應(yīng)用層使用sendto發(fā)送了一個(gè)邏輯包之后，在接收端通過(guò)recvfrom接收到的就是剛才使用sendto發(fā)送的那個(gè)邏輯包，這個(gè)包不會(huì)被分開(kāi)發(fā)送，也不會(huì)與其它的包放在一起發(fā)送。但對(duì)于TCP而言，TCP會(huì)根據(jù)網(wǎng)絡(luò)狀況和neagle算法，或者將一個(gè)邏輯包單獨(dú)發(fā)送，或者將一個(gè)邏輯包分成若干次發(fā)送，或者會(huì)將若干個(gè)邏輯包合在一起發(fā)送出去。正因?yàn)門(mén)CP在邏輯包處理方面的這種粘合性，要求我們?cè)谧骰赥CP的應(yīng)用時(shí)，一般都要編寫(xiě)相應(yīng)的拼包、解包代碼。

　　因此，基于TCP的上層應(yīng)用，一般都要定義自己的包格式。TCP的封包定義中，除了具體的數(shù)據(jù)內(nèi)容所代表的邏輯意義之外，第一步就是要確定以何種方式表示當(dāng)前包的開(kāi)始和結(jié)束。通常情況下，表示一個(gè)TCP邏輯包的開(kāi)始和結(jié)束有兩種方式：
　　1、以特殊的開(kāi)始和結(jié)束標(biāo)志表示，比如FF00表示開(kāi)始，00FF表示結(jié)束。
　　2、直接以包長(zhǎng)度來(lái)表示。比如可以用第一個(gè)字節(jié)表示包總長(zhǎng)度，如果覺(jué)得這樣的話包比較小，也可以用兩個(gè)字節(jié)表示包長(zhǎng)度。

　　下面將要給出的代碼是以第2種方式定義的數(shù)據(jù)包，包長(zhǎng)度以每個(gè)封包的前兩個(gè)字節(jié)表示。我將結(jié)合著代碼給出相關(guān)的解釋和說(shuō)明。

　　函數(shù)中用到的變量說(shuō)明：

　　CLIENT_BUFFER_SIZE：緩沖區(qū)的長(zhǎng)度，定義為：Const int CLIENT_BUFFER_SIZE=4096。
　　m_ClientDataBuf：數(shù)據(jù)整理緩沖區(qū)，每次收到的數(shù)據(jù)，都會(huì)先被復(fù)制到這個(gè)緩沖區(qū)的末尾，然后由下面的整理函數(shù)對(duì)這個(gè)緩沖區(qū)進(jìn)行整理。它的定義是：char m_ClientDataBuf[2* CLIENT_BUFFER_SIZE]。
　　m_DataBufByteCount：數(shù)據(jù)整理緩沖區(qū)中當(dāng)前剩余的未整理字節(jié)數(shù)。
　　GetPacketLen(const char*)：函數(shù)，可以根據(jù)傳入的緩沖區(qū)首址按照應(yīng)用層協(xié)議取出當(dāng)前邏輯包的長(zhǎng)度。
　　GetGamePacket(const char*, int)：函數(shù)，可以根據(jù)傳入的緩沖區(qū)生成相應(yīng)的游戲邏輯數(shù)據(jù)包。
　　AddToExeList(PBaseGamePacket)：函數(shù)，將指定的游戲邏輯數(shù)據(jù)包加入待處理的游戲邏輯數(shù)據(jù)包隊(duì)列中，等待邏輯處理線程對(duì)其進(jìn)行處理。
　　DATA_POS：指的是除了包長(zhǎng)度、包類型等這些標(biāo)志型字段之外，真正的數(shù)據(jù)包內(nèi)容的起始位置。

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

 　//先將本次收到的數(shù)據(jù)復(fù)制到整理緩沖區(qū)尾部
    startPos = m_DataBufByteCount; 
    memcpy( m_ClientDataBuf+startPos, pData, len );
    m_DataBufByteCount += len;   

    //當(dāng)整理緩沖區(qū)內(nèi)的字節(jié)數(shù)少于DATA_POS字節(jié)時(shí)，取不到長(zhǎng)度信息則退出
　//注意：退出時(shí)并不置m_DataBufByteCount為0
    if (m_DataBufByteCount < DATA_POS+1)
        return false;

    //根據(jù)正常邏輯，下面的情況不可能出現(xiàn)，為穩(wěn)妥起見(jiàn)，還是加上
    if (m_DataBufByteCount >  2*CLIENT_BUFFER_SIZE)
    {
        //設(shè)置m_DataBufByteCount為0，意味著丟棄緩沖區(qū)中的現(xiàn)有數(shù)據(jù)
        m_DataBufByteCount = 0;

　　//可以考慮開(kāi)放錯(cuò)誤格式數(shù)據(jù)包的處理接口，處理邏輯交給上層
　　//OnPacketError()
        return false;
    }

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

     //只有當(dāng)m_ClientDataBuf中的字節(jié)個(gè)數(shù)大于最小包長(zhǎng)度時(shí)才能執(zhí)行此語(yǔ)句
    packetLen = GetPacketLen( pIOCPClient->m_ClientDataBuf );

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

　　//OnPacketError()
        return false;
    }

    //保留整理緩沖區(qū)的末尾指針
    __int64 oldlen = m_DataBufByteCount;

    while ((packetLen <= m_DataBufByteCount) && (m_DataBufByteCount>0))
    {
        //調(diào)用拼包邏輯，獲取該緩沖區(qū)數(shù)據(jù)對(duì)應(yīng)的數(shù)據(jù)包
        pGamePacket = GetGamePacket(m_ClientDataBuf+startPos, packetLen);

        if (pGamePacket!=NULL)
        {
            //將數(shù)據(jù)包加入執(zhí)行隊(duì)列
            AddToExeList(pGamePacket);
        }

        pGamePacket = NULL;
 
　　//整理緩沖區(qū)的剩余字節(jié)數(shù)和新邏輯包的起始位置進(jìn)行調(diào)整
        m_DataBufByteCount -= packetLen;
        startPos += packetLen;

        //殘留緩沖區(qū)的字節(jié)數(shù)少于一個(gè)正常包大小時(shí)，只向前復(fù)制該包隨后退出
        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 );

         //當(dāng)邏輯層的包長(zhǎng)度不合法時(shí)，丟棄該包及緩沖區(qū)以后的包
        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;
}

　　以上便是數(shù)據(jù)接收模塊的處理函數(shù)，下面是幾點(diǎn)簡(jiǎn)要說(shuō)明：

　　1、用于拼包整理的緩沖區(qū)(m_ClientDataBuf)應(yīng)該比recv中指定的接收緩沖區(qū)(pData)長(zhǎng)度(CLIENT_BUFFER_SIZE)要大，通常前者是后者的2倍(2*CLIENT_BUFFER_SIZE)或更大。

　　2、為避免因?yàn)槭Ｓ鄶?shù)據(jù)前移而導(dǎo)致的額外開(kāi)銷(xiāo)，建議m_ClientDataBuf使用環(huán)形緩沖區(qū)實(shí)現(xiàn)。

　　3、為了避免出現(xiàn)無(wú)法拼裝的包，我們約定每次發(fā)送的邏輯包，其單個(gè)邏輯包最大長(zhǎng)度不可以超過(guò)CLIENT_BUFFER_SIZE的2倍。因?yàn)槲覀兊恼砭彌_區(qū)只有2*CLIENT_BUFFER_SIZE這么長(zhǎng)，更長(zhǎng)的數(shù)據(jù)，我們將無(wú)法整理。這就要求在協(xié)議的設(shè)計(jì)上以及最終的發(fā)送函數(shù)的處理上要加上這樣的異常處理機(jī)制。

　　4、對(duì)于數(shù)據(jù)包過(guò)短或過(guò)長(zhǎng)的包，我們通常的情況是置m_DataBufByteCount為0，即舍棄當(dāng)前包的處理。如果此處不設(shè)置m_DataBufByteCount為0也可，但該客戶端只要發(fā)了一次格式錯(cuò)誤的包，則其后繼發(fā)過(guò)來(lái)的包則也將連帶著產(chǎn)生格式錯(cuò)誤，如果設(shè)置m_DataBufByteCount為0，則可以比較好的避免后繼的包受此包的格式錯(cuò)誤影響。更好的作法是，在此處開(kāi)放一個(gè)封包格式異常的處理接口(OnPacketError)，由上層邏輯決定對(duì)這種異常如何處置。比如上層邏輯可以對(duì)封包格式方面出現(xiàn)的異常進(jìn)行計(jì)數(shù)，如果錯(cuò)誤的次數(shù)超過(guò)一定的值，則可以斷開(kāi)該客戶端的連接。

　　5、建議不要在recv或wsarecv的函數(shù)后，就緊接著作以上的處理。當(dāng)recv收到一段數(shù)據(jù)后，生成一個(gè)結(jié)構(gòu)體或?qū)ο?它主要含有data和len兩個(gè)內(nèi)容，前者是數(shù)據(jù)緩沖區(qū)，后者是數(shù)據(jù)長(zhǎng)度)，將這樣的一個(gè)結(jié)構(gòu)體或?qū)ο蠓诺揭粋€(gè)隊(duì)列中由后面的線程對(duì)其使用SplitFun函數(shù)進(jìn)行整理。這樣，可以最大限度地提高網(wǎng)絡(luò)數(shù)據(jù)的接收速度，不至因?yàn)閿?shù)據(jù)整理的原因而在此處浪費(fèi)時(shí)間。

　　代碼中，我已經(jīng)作了比較詳細(xì)的注釋，可以作為拼包函數(shù)的參考，代碼是從偶的應(yīng)用中提取、修改而來(lái)，本身只為演示之用，所以未作調(diào)試，應(yīng)用時(shí)需要你自己去完善。如有疑問(wèn)，可以我的blog上留言提出。

本文來(lái)自CSDN博客，轉(zhuǎn)載請(qǐng)標(biāo)明出處：http://blog.csdn.net/clever101/archive/2008/10/12/3061679.aspx