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

                                                        
            久久电影网2021| 国产精品久久永久免费| 精品一久久香蕉国产线看播放| 99久久精品国产免看国产一区| 久久精品免费网站网| 亚洲国产综合久久天堂| 久久精品国产亚洲av影院| 香蕉久久夜色精品国产小说| 无码任你躁久久久久久老妇| av无码久久久久久不卡网站| 日本欧美国产精品第一页久久| 久久综合国产乱子伦精品免费| 成人精品一区二区久久久| 国产激情久久久久久熟女老人| 久久99国产精品99久久| 性做久久久久久久久浪潮| 国产精品成人99久久久久91gav| 久久精品国产亚洲αv忘忧草| 91精品国产高清久久久久久91| 久久精品中文无码资源站| 东京热TOKYO综合久久精品| 亚洲精品综合久久| 久久国产乱子伦精品免费午夜| 久久99国产精品久久99果冻传媒| 一本久久知道综合久久| 亚洲国产精品成人AV无码久久综合影院| 久久精品国产99久久久| 久久影院综合精品| 99蜜桃臀久久久欧美精品网站| 欧美日韩精品久久久免费观看| 国产国产成人久久精品 | 国产精品视频久久久| 亚洲av伊人久久综合密臀性色 | 粉嫩小泬无遮挡久久久久久| 2021国产精品久久精品| 无码人妻少妇久久中文字幕 | 久久久久久亚洲Av无码精品专口| 久久综合亚洲鲁鲁五月天| 久久乐国产精品亚洲综合| 国产成人无码精品久久久免费| 大香网伊人久久综合网2020|