• <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>

            牽著老婆滿街逛

            嚴(yán)以律己,寬以待人. 三思而后行.
            GMail/GTalk: yanglinbo#google.com;
            MSN/Email: tx7do#yahoo.com.cn;
            QQ: 3 0 3 3 9 6 9 2 0 .

            UDP丟包原因

            轉(zhuǎn)載自:http://www.cnblogs.com/mengyan/archive/2012/10/04/2711340.html

            一、主要丟包原因

            1、接收端處理時間過長導(dǎo)致丟包:調(diào)用recv方法接收端收到數(shù)據(jù)后,處理數(shù)據(jù)花了一些時間,處理完后再次調(diào)用recv方法,在這二次調(diào)用間隔里,發(fā)過來的包可能丟失。對于這種情況可以修改接收端,將包接收后存入一個緩沖區(qū),然后迅速返回繼續(xù)recv。

            2、發(fā)送的包巨大丟包:雖然send方法會幫你做大包切割成小包發(fā)送的事情,但包太大也不行。例如超過50K的一個udp包,不切割直接通過send方法發(fā)送也會導(dǎo)致這個包丟失。這種情況需要切割成小包再逐個send。

            3、發(fā)送的包較大,超過接受者緩存導(dǎo)致丟包:包超過mtu size數(shù)倍,幾個大的udp包可能會超過接收者的緩沖,導(dǎo)致丟包。這種情況可以設(shè)置socket接收緩沖。以前遇到過這種問題,我把接收緩沖設(shè)置成64K就解決了。
            int nRecvBuf=32*1024;//設(shè)置為32K
            setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int));

            具體設(shè)置代碼可以參考下面鏈接:
            http://blog.sina.com.cn/s/blog_a459dcf5010153mp.html

            4、發(fā)送的包頻率太快:雖然每個包的大小都小于mtu size 但是頻率太快,例如40多個mut size的包連續(xù)發(fā)送中間不sleep,也有可能導(dǎo)致丟包。這種情況也有時可以通過設(shè)置socket接收緩沖解決,但有時解決不了。所以在發(fā)送頻率過快的時候還是考慮sleep一下吧。

            5、局域網(wǎng)內(nèi)不丟包,公網(wǎng)上丟包。這個問題我也是通過切割小包并sleep發(fā)送解決的。如果流量太大,這個辦法也不靈了。總之udp丟包總是會有的,如果出現(xiàn)了用我的方法解決不了,還有這個幾個方法: 要么減小流量,要么換tcp協(xié)議傳輸,要么做丟包重傳的工作。

             

             

            二、具體問題分析

            1.發(fā)送頻率過高導(dǎo)致丟包

            很多人會不理解發(fā)送速度過快為什么會產(chǎn)生丟包,原因就是UDP的SendTo不會造成線程阻塞,也就是說,UDP的SentTo不會像TCP中的SendTo那樣,直到數(shù)據(jù)完全發(fā)送才會return回調(diào)用函數(shù),它不保證當(dāng)執(zhí)行下一條語句時數(shù)據(jù)是否被發(fā)送。(SendTo方法是異步的)這樣,如果要發(fā)送的數(shù)據(jù)過多或者過大,那么在緩沖區(qū)滿的那個瞬間要發(fā)送的報文就很有可能被丟失。至于對“過快”的解釋,作者這樣說:“A few packets a second are not an issue; hundreds or thousands may be an issue.”(一秒鐘幾個數(shù)據(jù)包不算什么,但是一秒鐘成百上千的數(shù)據(jù)包就不好辦了)。 要解決接收方丟包的問題很簡單,首先要保證程序執(zhí)行后馬上開始監(jiān)聽(如果數(shù)據(jù)包不確定什么時候發(fā)過來的話),其次,要在收到一個數(shù)據(jù)包后最短的時間內(nèi)重新回到監(jiān)聽狀態(tài),其間要盡量避免復(fù)雜的操作(比較好的解決辦法是使用多線程回調(diào)機(jī)制)。

            2.報文過大丟包

            至于報文過大的問題,可以通過控制報文大小來解決,使得每個報文的長度小于MTU。以太網(wǎng)的MTU通常是1500 bytes,其他一些諸如撥號連接的網(wǎng)絡(luò)MTU值為1280 bytes,如果使用speaking這樣很難得到MTU的網(wǎng)絡(luò),那么最好將報文長度控制在1280 bytes以下。

            3.發(fā)送方丟包

            發(fā)送方丟包:內(nèi)部緩沖區(qū)(internal buffers)已滿,并且發(fā)送速度過快(即發(fā)送兩個報文之間的間隔過短);  接收方丟包:Socket未開始監(jiān)聽;  雖然UDP的報文長度最大可以達(dá)到64 kb,但是當(dāng)報文過大時,穩(wěn)定性會大大減弱。這是因為當(dāng)報文過大時會被分割,使得每個分割塊(翻譯可能有誤差,原文是fragmentation)的長度小于MTU,然后分別發(fā)送,并在接收方重新組合(reassemble),但是如果其中一個報文丟失,那么其他已收到的報文都無法返回給程序,也就無法得到完整的數(shù)據(jù)了。 

            posted on 2013-01-15 15:20 楊粼波 閱讀(936) 評論(0)  編輯 收藏 引用


            只有注冊用戶登錄后才能發(fā)表評論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            岛国搬运www久久| 囯产极品美女高潮无套久久久 | 一日本道伊人久久综合影| 亚洲国产成人久久一区WWW| 亚洲综合精品香蕉久久网| 国产精品久久毛片完整版| 久久综合九色综合欧美就去吻| 久久久久无码精品国产不卡| 久久影院午夜理论片无码| 精品乱码久久久久久久| 欧美激情精品久久久久久| 99久久婷婷免费国产综合精品| 一本久久精品一区二区| 91久久精品无码一区二区毛片| 国产精品99久久久精品无码| 久久不见久久见免费影院www日本| 亚洲色欲久久久综合网| 亚洲国产成人久久笫一页| 亚洲国产精品久久久久| 久久精品国产亚洲精品2020| 久久笫一福利免费导航 | 久久精品国产99久久久古代 | 四虎国产精品免费久久| 久久精品人人做人人爽电影| 99精品国产99久久久久久97| 美女久久久久久| 久久精品无码免费不卡| 香蕉久久夜色精品国产小说| 久久精品亚洲日本波多野结衣| 一本色道久久HEZYO无码| 亚洲人成无码网站久久99热国产| 国产精品成人99久久久久| 久久精品国产秦先生| 亚洲国产精品久久久久婷婷老年 | 无码人妻久久久一区二区三区 | 久久精品成人国产午夜| 亚洲国产精品一区二区久久| 一本大道加勒比久久综合| 国产高清国内精品福利99久久| 国产成人无码精品久久久久免费| 国产福利电影一区二区三区,免费久久久久久久精 |