• <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 冰果 閱讀(1886) 評論(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,如果是阻塞通訊,客戶端就會卡這里了。  回復  更多評論   

                                                        
            精品久久一区二区三区| 久久免费视频1| 一本一道久久精品综合| 久久久WWW免费人成精品| 色妞色综合久久夜夜| 热re99久久精品国产99热| 亚洲国产成人久久综合碰| 久久91精品久久91综合| 区亚洲欧美一级久久精品亚洲精品成人网久久久久 | 亚州日韩精品专区久久久| 麻豆亚洲AV永久无码精品久久 | 久久精品国产精品亚洲| 亚洲精品乱码久久久久久中文字幕 | 国产国产成人精品久久| 中文精品99久久国产| a级毛片无码兔费真人久久 | 中文字幕成人精品久久不卡| 亚洲人成精品久久久久| 精品久久久无码中文字幕天天| 一本色综合网久久| 日韩十八禁一区二区久久 | 精品综合久久久久久97超人| 久久久久亚洲AV片无码下载蜜桃| 国产成人AV综合久久| 成人妇女免费播放久久久| 亚洲中文精品久久久久久不卡| 久久天天躁狠狠躁夜夜av浪潮 | 伊人久久大香线蕉AV一区二区 | 一本久久a久久精品vr综合| 久久久久久免费视频| 亚洲а∨天堂久久精品9966| 久久青青草原精品国产不卡| 国内精品免费久久影院| 国产免费福利体检区久久 | 久久99精品国产99久久6男男| 99蜜桃臀久久久欧美精品网站 | 青青国产成人久久91网| 国产人久久人人人人爽| 91精品国产9l久久久久| 99热成人精品免费久久| 久久久久亚洲精品无码网址|