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

            冰果

            技術群:26678700     
            交流QQ: 704839634
            合作: 1) 可兼職遠程辦公開發; 2) 有一套Go+Python開發的行業短信云平臺可合作;3)目前正在開發物聯網、大數據平臺。

            還是要學習一點網絡通訊的基本原理

                     總會看到c++新手寫網絡通訊時,不理解recv()為什么阻塞或不阻塞,TCP數據順序會不會亂,UDP會不會數據包不完整,都是對TCP/IP協議原理沒有基本常識導致的。

                     我曾看到代碼,客戶端recv(buf, 31), 實際服務器只會發送4個字節,客戶端將永遠阻塞,直到服務器主動close()為止。

            開始時那個服務器是實現一請求一應答,答應后立即關閉,所以客戶端沒有事。

                     后來服務器維護者,感覺要支持一個連接上支持一個或多個請求,就修改成等待客戶端自己關閉或網絡異常,服務器才關閉socket。這個修改看來是正常的,因為服務器一般寫法都是被動關閉的,關閉權在客戶端。可是這么一修改,原來那個客戶端就阻塞死了,用戶莫名其妙。

                     這里有一個有趣現象:如果服務器維護者不修改,那么那個客戶端軟件一直是可以正常運行的,但從我們開發者角度來看,明明是一種實現錯誤,至少是缺陷吧。可是,測試人員黑盒測試是不可能測試出來的,一般測試人員也不會去寫代碼測試,所以這種問題測試組搞不定。

                     很多時候,在測試環境里沒問題,在真實環境就出現一些古怪的問題,其實問題不古怪。

                     比如:A通過TCP向B發送1024字節,B采用一次性接收recv(buf, 1024), 測試環境常常每次都是一次收滿,包是完整的;在真實環境,A和B在不同地域,之間不知道多少交換機和路由器,那可能就第一次只收到500字節,如果不加判斷返回值亂處理,問題就出來了。

                     這個問題還不止一次看到新手這么干。

            posted on 2012-03-06 21:36 冰果 閱讀(1898) 評論(4)  編輯 收藏 引用

            評論

            # re: 還是要學習一點網絡通訊的基本原理 2012-03-07 09:24 winsock

            我曾看到代碼,客戶端recv(buf, 31), 實際服務器只會發送4個字節,客戶端將永遠阻塞,直到服務器主動close()為止。

            …………………………………………………………………………………………………………
            不敢茍同這個啊。服務器就算發送1字節,recv(buf, 31)也會返回的。  回復  更多評論   

            # re: 還是要學習一點網絡通訊的基本原理 2012-03-07 09:50 flyliying

            同意 winsock 的看法,會返回。不然這個recv怎么寫?  回復  更多評論   

            # re: 還是要學習一點網絡通訊的基本原理 2012-03-07 12:44 核子

            我也認為你說的recv有問題  回復  更多評論   

            # re: 還是要學習一點網絡通訊的基本原理[未登錄] 2012-03-07 15:41 ithaca

            @winsock

            嗯,
            若:
            客戶端recv(buf, 31), 實際服務器只會發送4個字節
            則:
            客戶端不會阻塞,recv返回4,
            這時:
            看你應用程序的行為了。

            博主的意思是大概是通過判斷recv(buf, 31)的返回值為4,知道不收夠31字節就再接著recv,如果是阻塞通訊,客戶端就會卡這里了。  回復  更多評論   

                                                        
            亚洲精品无码久久久久去q| 91精品国产91久久久久久蜜臀| 亚洲国产日韩欧美久久| 久久久久亚洲AV成人网人人网站| 亚洲精品tv久久久久久久久| 亚洲乱亚洲乱淫久久| 亚洲国产精品无码久久青草| 国产精品无码久久久久久| 伊人久久一区二区三区无码| 99久久er这里只有精品18| 亚洲日韩欧美一区久久久久我| 久久久久人妻一区二区三区vr| 久久国产成人精品国产成人亚洲| 奇米影视7777久久精品| 久久久亚洲精品蜜桃臀| 久久香蕉国产线看观看乱码| 国产亚洲精品久久久久秋霞| 久久精品成人免费观看97| 久久99精品久久久久久久不卡| 国产69精品久久久久APP下载| 韩国三级大全久久网站| 久久精品成人欧美大片| 合区精品久久久中文字幕一区| 国产成人久久精品麻豆一区| a高清免费毛片久久| 久久国产精品99精品国产| 亚洲AV无码久久精品狠狠爱浪潮| 久久久久久久亚洲精品| 国产一区二区精品久久凹凸 | 亚洲婷婷国产精品电影人久久| 久久天堂AV综合合色蜜桃网| 色妞色综合久久夜夜| 久久只有这精品99| 最新久久免费视频| 香蕉久久夜色精品国产尤物| 欧美亚洲日本久久精品| 欧美午夜A∨大片久久| 亚洲精品无码久久不卡| 国产精品久久久久免费a∨| 久久99九九国产免费看小说| 亚洲日本久久久午夜精品|