• <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年5月>
            2526272829301
            2345678
            9101112131415
            16171819202122
            23242526272829
            303112345

            享受編程

            常用鏈接

            留言簿(11)

            隨筆分類(159)

            隨筆檔案(224)

            文章分類(2)

            文章檔案(4)

            經典c++博客

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

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

            這兩天看csdn有一些關于socket粘包,socket緩沖區設置的問題,發現自己不是很清楚,所以查資料了解記錄一下:

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

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

            2.短連接

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

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

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

            2:如果發送數據無結構,如文件傳輸,這樣發送方只管發送,接收方只管接收存儲就ok,也不用考慮粘包

            3:如果雙方建立連接,需要在連接后一段時間內發送不同結構數據,如連接后,有好幾種結構:
            1)"hello give me sth abour yourself"
            2)"Don't give me sth abour yourself" 

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

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

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

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


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

            在socket 文件傳輸中,獲取某個目錄下的所有文件,如果一個文件名傳輸一次通訊的話,127.0.0.1上測試沒有什么問題,當在局域網中傳輸2次以上,就會出現包丟失問題。我猜這個問題跟粘包有點相似。
            posted on 2010-10-11 17:23 漂漂 閱讀(694) 評論(0)  編輯 收藏 引用 所屬分類: 深入vc++
            国产99久久九九精品无码| 久久91精品国产91| 99久久精品免费| 日韩欧美亚洲综合久久影院Ds| 久久大香萑太香蕉av| 久久精品国内一区二区三区| 久久有码中文字幕| 久久精品人人做人人爽电影蜜月 | 亚洲av成人无码久久精品| 久久精品国产一区二区三区日韩| 亚洲精品乱码久久久久久不卡| 91精品国产高清久久久久久io| 久久国产亚洲精品| 久久久久久久综合综合狠狠| 久久久久人妻一区精品色| 区亚洲欧美一级久久精品亚洲精品成人网久久久久| 久久综合国产乱子伦精品免费| 久久久久久国产精品无码下载| 久久久无码精品亚洲日韩蜜臀浪潮 | 午夜天堂av天堂久久久| 青青热久久国产久精品| 99久久99久久精品国产片果冻| 日韩精品久久无码中文字幕| 久久亚洲中文字幕精品一区| 欧美久久天天综合香蕉伊| 久久精品草草草| 国产成人精品久久二区二区 | 国内精品免费久久影院| 色欲久久久天天天综合网精品 | 久久永久免费人妻精品下载| 人妻少妇精品久久| 香蕉久久AⅤ一区二区三区| 久久久久国色AV免费观看| 国产成人无码精品久久久免费| AV色综合久久天堂AV色综合在 | 午夜精品久久影院蜜桃| 四虎亚洲国产成人久久精品| 久久成人小视频| 久久夜色精品国产欧美乱| 国产91色综合久久免费| 久久综合九色综合久99 |