• <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>
            隨筆 - 224  文章 - 41  trackbacks - 0
            <2010年8月>
            25262728293031
            1234567
            891011121314
            15161718192021
            22232425262728
            2930311234

            享受編程

            常用鏈接

            留言簿(11)

            隨筆分類(159)

            隨筆檔案(224)

            文章分類(2)

            文章檔案(4)

            經(jīng)典c++博客

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            原文地址:http://www.shnenglu.com/lapcca/archive/2010/09/10/126329.html

            這兩天看csdn有一些關(guān)于socket粘包,socket緩沖區(qū)設(shè)置的問題,發(fā)現(xiàn)自己不是很清楚,所以查資料了解記錄一下:

            一兩個簡單概念長連接與短連接:
            1.長連接

                Client方與Server方先建立通訊連接,連接建立后不斷開, 然后再進行報文發(fā)送和接收。

            2.短連接

                Client方與Server每進行一次報文收發(fā)交易時才進行通訊連接,交易完畢后立即斷開連接。此種方式常用于一點對多點
            通訊,比如多個Client連接一個Server.

            二 什么時候需要考慮粘包問題?

            1:如果利用tcp每次發(fā)送數(shù)據(jù),就與對方建立連接,然后雙方發(fā)送完一段數(shù)據(jù)后,就關(guān)閉連接,這樣就不會出現(xiàn)粘包問題(因為只有一種包結(jié)構(gòu),類似于http協(xié)議)。關(guān)閉連接主要要雙方都發(fā)送close連接(參考tcp關(guān)閉協(xié)議)。如:A需要發(fā)送一段字符串給B,那么A與B建立連接,然后發(fā)送雙方都默認好的協(xié)議字符如"hello give me sth abour yourself",然后B收到報文后,就將緩沖區(qū)數(shù)據(jù)接收,然后關(guān)閉連接,這樣粘包問題不用考慮到,因為大家都知道是發(fā)送一段字符。

            2:如果發(fā)送數(shù)據(jù)無結(jié)構(gòu),如文件傳輸,這樣發(fā)送方只管發(fā)送,接收方只管接收存儲就ok,也不用考慮粘包

            3:如果雙方建立連接,需要在連接后一段時間內(nèi)發(fā)送不同結(jié)構(gòu)數(shù)據(jù),如連接后,有好幾種結(jié)構(gòu):
            1)"hello give me sth abour yourself"
            2)"Don't give me sth abour yourself" 

             那這樣的話,如果發(fā)送方連續(xù)發(fā)送這個兩個包出去,接收方一次接收可能會是"hello give me sth abour yourselfDon't give me sth abour yourself" 這樣接收方就傻了,到底是要干嘛?不知道,因為協(xié)議沒有規(guī)定這么詭異的字符串,所以要處理把它分包,怎么分也需要雙方組織一個比較好的包結(jié)構(gòu),所以一般可能會在頭加一個數(shù)據(jù)長度之類的包,以確保接收。

            三 粘包出現(xiàn)原因:在流傳輸中出現(xiàn),UDP不會出現(xiàn)粘包,因為它有消息邊界(參考Windows 網(wǎng)絡(luò)編程)
            1 發(fā)送端需要等緩沖區(qū)滿才發(fā)送出去,造成粘包
            2 接收方不及時接收緩沖區(qū)的包,造成多個包接收

            解決辦法:
            為了避免粘包現(xiàn)象,可采取以下幾種措施。一是對于發(fā)送方引起的粘包現(xiàn)象,用戶可通過編程設(shè)置來避免,TCP提供了強制數(shù)據(jù)立即傳送的操作指令push,TCP軟件收到該操作指令后,就立即將本段數(shù)據(jù)發(fā)送出去,而不必等待發(fā)送緩沖區(qū)滿;二是對于接收方引起的粘包,則可通過優(yōu)化程序設(shè)計、精簡接收進程工作量、提高接收進程優(yōu)先級等措施,使其及時接收數(shù)據(jù),從而盡量避免出現(xiàn)粘包現(xiàn)象;三是由接收方控制,將一包數(shù)據(jù)按結(jié)構(gòu)字段,人為控制分多次接收,然后合并,通過這種手段來避免粘包。

            以上提到的三種措施,都有其不足之處。第一種編程設(shè)置方法雖然可以避免發(fā)送方引起的粘包,但它關(guān)閉了優(yōu)化算法,降低了網(wǎng)絡(luò)發(fā)送效率,影響應(yīng)用程序的性能,一般不建議使用。第二種方法只能減少出現(xiàn)粘包的可能性,但并不能完全避免粘包,當發(fā)送頻率較高時,或由于網(wǎng)絡(luò)突發(fā)可能使某個時間段數(shù)據(jù)包到達接收方較快,接收方還是有可能來不及接收,從而導(dǎo)致粘包。第三種方法雖然避免了粘包,但應(yīng)用程序的效率較低,對實時應(yīng)用的場合不適合。


            解決粘包問題:http://www.vckbase.com/document/viewdoc/?id=1203

            在socket 文件傳輸中,獲取某個目錄下的所有文件,如果一個文件名傳輸一次通訊的話,127.0.0.1上測試沒有什么問題,當在局域網(wǎng)中傳輸2次以上,就會出現(xiàn)包丟失問題。我猜這個問題跟粘包有點相似。
            posted on 2010-10-11 17:23 漂漂 閱讀(694) 評論(0)  編輯 收藏 引用 所屬分類: 深入vc++
            久久这里的只有是精品23| 久久久精品视频免费观看| 无码乱码观看精品久久| 狠狠色丁香婷婷久久综合五月| 久久久久亚洲AV无码专区桃色| 欧美亚洲另类久久综合婷婷| 99久久国产亚洲综合精品| 国内精品久久久久久久97牛牛| 丰满少妇高潮惨叫久久久| 国产成人综合久久精品尤物| 久久精品国产色蜜蜜麻豆| 久久精品毛片免费观看| 久久国产精品免费| 久久成人国产精品二三区| 国产精品嫩草影院久久| 国内精品伊人久久久久av一坑 | 久久久久亚洲av毛片大| 久久九九青青国产精品| 久久婷婷成人综合色综合| 一本综合久久国产二区| 欧美麻豆久久久久久中文| 久久精品国产一区二区| 狠狠久久综合| 久久人人爽人人爽人人片AV麻烦| 欧美久久一区二区三区| 久久久黄色大片| 成人国内精品久久久久一区| 久久人爽人人爽人人片AV | 久久国产视频网| 久久精品国产亚洲7777| 四虎影视久久久免费观看| 亚洲精品午夜国产VA久久成人| 久久久久久国产a免费观看黄色大片| 免费精品久久天干天干| 手机看片久久高清国产日韩| 久久精品久久久久观看99水蜜桃 | 久久久亚洲精品蜜桃臀| 亚洲精品tv久久久久| 国产产无码乱码精品久久鸭| 热99RE久久精品这里都是精品免费 | 久久综合九色综合网站|