• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            教父的告白
            一切都是紙老虎
            posts - 82,  comments - 7,  trackbacks - 0

            本文作者:sodme
            本文出處:http://blog.csdn.net/sodme
            聲明:本文可以不經(jīng)作者同意任意轉(zhuǎn)載、復(fù)制、傳播,但任何對本文的引用都請保留作者、出處及本聲明信息。謝謝!

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

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

              關(guān)于網(wǎng)絡(luò)封包方面的異常,總體來說,可以分為兩大類:一是封包格式出現(xiàn)異常;二是封包內(nèi)容(即封包數(shù)據(jù))出現(xiàn)異常。在封包格式的異常處理方面, 我們在最底端的網(wǎng)絡(luò)數(shù)據(jù)包接收模塊便可以加以處理。而對于封包數(shù)據(jù)內(nèi)容出現(xiàn)的異常,只有依靠游戲本身的邏輯去加以判定和檢驗(yàn)。游戲邏輯方面的異常處理,是 隨每個游戲的不同而不同的,所以,本文隨后的內(nèi)容將重點(diǎn)闡述在網(wǎng)絡(luò)數(shù)據(jù)包接收模塊中的異常處理。

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

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

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

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

              函數(shù)中用到的變量說明:

              CLIENT_BUFFER_SIZE:緩沖區(qū)的長度,定義為:Const int CLIENT_BUFFER_SIZE=4096。
              m_ClientDataBuf:數(shù)據(jù)整理緩沖區(qū),每次收到的數(shù)據(jù),都會先被復(fù)制到這個緩沖區(qū)的末尾,然后由下面的整理函數(shù)對這個緩沖區(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)前邏輯包的長度。
              GetGamePacket(const char*, int):函數(shù),可以根據(jù)傳入的緩沖區(qū)生成相應(yīng)的游戲邏輯數(shù)據(jù)包。
              AddToExeList(PBaseGamePacket):函數(shù),將指定的游戲邏輯數(shù)據(jù)包加入待處理的游戲邏輯數(shù)據(jù)包隊列中,等待邏輯處理線程對其進(jìn)行處理。
              DATA_POS:指的是除了包長度、包類型等這些標(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é)時,取不到長度信息則退出
             //注意:退出時并不置m_DataBufByteCount為0
                if (m_DataBufByteCount < DATA_POS+1)
                    return false; 

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

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

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

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

                //當(dāng)邏輯層的包長度不合法時,則直接丟棄該包
                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ù)對應(yīng)的數(shù)據(jù)包
                    pGamePacket = GetGamePacket(m_ClientDataBuf+startPos, packetLen); 

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

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

                    //殘留緩沖區(qū)的字節(jié)數(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)邏輯層的包長度不合法時,丟棄該包及緩沖區(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)簡要說明:

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

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

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


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

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

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

            posted on 2009-09-23 23:47 暗夜教父 閱讀(736) 評論(0)  編輯 收藏 引用 所屬分類: Game Development

            <2009年10月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            常用鏈接

            留言簿(2)

            隨筆分類

            隨筆檔案

            文章分類

            文章檔案

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            91精品国产91久久久久久青草| 亚洲国产成人久久一区WWW| 欧美麻豆久久久久久中文| 99久久精品国内| 久久99精品国产99久久6男男| 国产亚洲婷婷香蕉久久精品| 一本久久a久久精品综合香蕉| 狠狠人妻久久久久久综合蜜桃| 久久亚洲中文字幕精品一区| 久久久久久精品免费看SSS| 亚洲精品乱码久久久久久蜜桃图片 | 日韩精品久久久久久久电影| 日本五月天婷久久网站| 欧美精品乱码99久久蜜桃| 久久人搡人人玩人妻精品首页| 久久av高潮av无码av喷吹| 国产精品内射久久久久欢欢| 97久久国产露脸精品国产| 久久99精品国产麻豆| 国产激情久久久久影院小草| 国产精品99久久久久久董美香| 国内精品久久久久久久影视麻豆| 国产精久久一区二区三区| 亚洲欧美精品一区久久中文字幕 | 久久久中文字幕日本| 久久久国产视频| 成人久久综合网| 亚洲国产天堂久久久久久| 色婷婷综合久久久中文字幕| 久久夜色精品国产亚洲av| 久久久久久综合网天天| 久久国产精品99精品国产987| 亚洲午夜久久久精品影院| 久久天天婷婷五月俺也去| 久久ZYZ资源站无码中文动漫| 久久久久久久97| 久久久久久a亚洲欧洲aⅴ | 国产精品禁18久久久夂久| 国产精品激情综合久久| 一本一本久久aa综合精品| 国产高潮久久免费观看|