• <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>

            socketref,再見!高德

            https://github.com/adoggie

              C++博客 :: 首頁(yè) :: 聯(lián)系 :: 聚合  :: 管理
              246 Posts :: 4 Stories :: 312 Comments :: 0 Trackbacks

            常用鏈接

            留言簿(54)

            我參與的團(tuán)隊(duì)

            搜索

            •  

            最新評(píng)論

            閱讀排行榜

            評(píng)論排行榜


            一友人做游戲服務(wù)器,涉及通信模塊和業(yè)務(wù)模塊,在軟件行業(yè)也算個(gè)老兵了,也搞c++n多年了,對(duì)于軟件開發(fā)也有自己的一些想法和心得,將其代碼與我分享,讓我觀贊一下。
            c++是我從業(yè)一來一直信奉的開發(fā)工具,雖然近些年一直用python來搞定應(yīng)用需求,但關(guān)鍵時(shí)刻還必須是c++搞定, 所以c++的程序代碼能hold住的。 

            我知道寫通信部分代碼的關(guān)鍵點(diǎn)在哪里,比如: 性能、安全、完整性、模塊化設(shè)計(jì)和處理,所以有針對(duì)性的去檢查友人的代碼,當(dāng)看到這個(gè)函數(shù)的時(shí)候,致命的錯(cuò)誤來了: 
            分別在于: 第 13,20行 ,其分別會(huì)導(dǎo)致服務(wù)器崩潰和不響應(yīng)

             1 
             2 tagPack* CClient::getRecvPack()
             3 {
             4     uv_mutex_lock(&_lockrecv);
             5     tagPack *t = NULL;
             6     if(_recvPackLenght < 4)
             7     {
             8         _recvOver = true;
             9         uv_mutex_unlock(&_lockrecv);
            10         return t;
            11     }
            12     tagPack* tmp = _lsRecvBuf.front();
            13     unsigned int size = *(unsigned int*)&tmp->pack[0];
            14     if(_recvPackLenght < size)
            15     {
            16         _recvOver = true;
            17         uv_mutex_unlock(&_lockrecv);
            18         return t;
            19     }
            20     BYTE* mem = new BYTE[size];
            21 
            22     unsigned int index = 0;
            23     unsigned int needSize = size;
            24     while(true)
            25     {
            26         if(tmp->size < needSize)
            27         {
            28             memcpy(&mem[index], tmp->pack, tmp->size);
            29             needSize -= tmp->size;
            30             index += tmp->size;
            31             delete tmp;
            32             _lsRecvBuf.pop_front();
            33         }
            34         else if(tmp->size == needSize)
            35         {
            36             memcpy(&mem[index], tmp->pack, tmp->size);
            37             needSize -= tmp->size;
            38             index += tmp->size;
            39             delete tmp;
            40             _lsRecvBuf.pop_front();
            41         }
            42         else
            43         {
            44             memcpy(&mem[index], tmp->pack, needSize);
            45             memcpy(tmp->pack, &tmp->pack[needSize], tmp->size - needSize);
            46             tmp->size -= needSize;
            47 
            48             needSize = 0;
            49         }
            50 
            51         if( needSize == 0 )
            52         {
            53             t = new tagPack(size);
            54             t->addBytes(mem, size);
            55             t->_sock = _sock;
            56             delete []mem;
            57             _recvPackLenght -= t->size;
            58             break;
            59         }
            60         tmp = _lsRecvBuf.front();
            61     }
            62     uv_mutex_unlock(&_lockrecv);
            63 
            64     return t;
            65 }

            13行:  開發(fā)者直接將緩存內(nèi)存地址作為接收和發(fā)送地址,沒考慮 字節(jié)序問題  (htonl,ntohl) 
            20行:  邏輯不嚴(yán)密,如果用戶發(fā)送4個(gè)字節(jié)數(shù)據(jù),且均為0 ,結(jié)果就是服務(wù)器崩潰。 

            所以codereview還是很重要的,特別是將c++應(yīng)用在性能,效率關(guān)鍵部位的代碼。 







            posted on 2016-03-24 15:29 放屁阿狗 閱讀(16285) 評(píng)論(4)  編輯 收藏 引用 所屬分類: C++/Boost/STL/Template

            Feedback

            # re: 有問題的c++通信代碼的識(shí)別 2016-03-26 22:28 火紅地太陽(yáng)
            這代碼能力,說實(shí)話,感覺太一般了,沒什么功底。  回復(fù)  更多評(píng)論
              

            # re: 有問題的c++通信代碼的識(shí)別 2016-03-27 00:23 放屁阿狗
            是不夠精簡(jiǎn),思路不夠嚴(yán)密  回復(fù)  更多評(píng)論
              

            # re: 有問題的c++通信代碼的識(shí)別[未登錄] 2016-04-12 11:36 hdqqq
            12 行沒檢查返回值
            53 行 new 一定成功嗎
              回復(fù)  更多評(píng)論
              

            # re: 有問題的c++通信代碼的識(shí)別 2016-05-06 09:36 tqt
            還new,還mutex_unlock,服.  回復(fù)  更多評(píng)論
              

            一本久久综合亚洲鲁鲁五月天亚洲欧美一区二区 | 亚洲午夜久久久影院伊人| 亚洲成色www久久网站夜月| 久久精品a亚洲国产v高清不卡| 国产成人精品久久一区二区三区av| 久久精品国产国产精品四凭 | 久久国产色av免费看| 欧美精品一区二区精品久久| 久久综合九色综合久99| 亚洲国产精品无码久久| 久久精品国产亚洲AV不卡| 99久久国产热无码精品免费| 久久精品国产亚洲av瑜伽| 99久久免费国产精品热| 亚洲伊人久久成综合人影院| 日韩精品久久久久久| 久久久精品2019免费观看| 一本一本久久a久久精品综合麻豆| 久久精品国产第一区二区三区| 亚洲精品无码久久不卡| 国产精品丝袜久久久久久不卡| 99精品久久精品一区二区| 久久国产午夜精品一区二区三区| 国产精品99久久99久久久| 精品久久久久成人码免费动漫| 国产午夜精品理论片久久| 久久婷婷五月综合色高清| 亚洲天堂久久久| 久久免费视频6| 国内精品久久久久久久影视麻豆 | 久久综合鬼色88久久精品综合自在自线噜噜 | 久久人人爽人人人人片av| 性欧美大战久久久久久久| 久久久艹| 香蕉久久影院| 久久SE精品一区二区| 国内精品综合久久久40p| 久久国语露脸国产精品电影 | 久久国产热这里只有精品| 国内精品久久久久久中文字幕 | 日韩精品久久久久久久电影蜜臀 |