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

                                                        
            女同久久| 成人综合久久精品色婷婷| 亚洲AV日韩精品久久久久久久| 久久AV无码精品人妻糸列| 久久人人爽人人爽人人AV| 久久免费精品视频| 亚洲国产香蕉人人爽成AV片久久 | 久久亚洲精品成人无码网站| 乱亲女H秽乱长久久久| 精品无码久久久久久久动漫| 亚洲午夜久久久影院伊人| 99久久国产主播综合精品| 日本五月天婷久久网站| 国产精品激情综合久久| 97r久久精品国产99国产精| 国产免费久久精品99re丫y| 99久久精品免费看国产免费| 色婷婷久久综合中文久久蜜桃av| 久久久久亚洲精品无码网址| 久久青青草原精品影院| 99久久超碰中文字幕伊人| 亚洲香蕉网久久综合影视| 久久91精品国产91| 久久久国产99久久国产一| 伊人色综合九久久天天蜜桃| 精品免费久久久久国产一区| 97精品伊人久久久大香线蕉| 久久国产精品一区二区| 久久精品国产亚洲欧美| 97r久久精品国产99国产精| 国产精品久久久久久久久鸭| 国产精品久久久久久一区二区三区| 午夜精品久久久久久毛片| 色欲久久久天天天综合网精品| 亚洲精品乱码久久久久久中文字幕 | 欧美久久久久久精选9999| 久久国产成人| 色偷偷91久久综合噜噜噜噜| 久久精品国产清自在天天线| 亚洲综合伊人久久综合| 国产精品久久精品|