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

                                                        
            久久亚洲欧美日本精品| 91久久精品国产91性色也| 亚洲精品乱码久久久久久蜜桃| 91精品国产综合久久香蕉| 精品久久久久久久中文字幕| 久久久久国色AV免费看图片| 久久婷婷五月综合色99啪ak| 99久久国产综合精品女同图片| 日韩精品无码久久久久久| 国产成人久久激情91| 欧美激情精品久久久久久久九九九| 狠狠色丁香婷婷久久综合| 99久久综合狠狠综合久久止| 亚洲欧美久久久久9999| 久久国产亚洲高清观看| 色综合久久久久综合99| 精品综合久久久久久888蜜芽| 久久久精品国产Sm最大网站| 三上悠亚久久精品| 久久综合九色综合欧美就去吻| 久久精品国产精品亚洲毛片| 伊人色综合九久久天天蜜桃| 国产精品久久国产精麻豆99网站| 亚洲国产精品综合久久网络| 26uuu久久五月天| 久久久无码人妻精品无码| 无夜精品久久久久久| 99国内精品久久久久久久| 69SEX久久精品国产麻豆| 精品久久久中文字幕人妻| 国产精品久久久久久久午夜片 | 久久国产一区二区| 久久久久久精品久久久久| 久久99精品久久久久久水蜜桃| 国产精品久久成人影院| 97久久精品人妻人人搡人人玩 | 久久久久久久综合日本| 久久99国产精品久久| 精品久久777| 久久精品99久久香蕉国产色戒| 国产A三级久久精品|