• <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丟包 又是udp丟包

            轉(zhuǎn)載自:http://www.cnweblog.com/fly2700/archive/2011/09/19/317825.html

            什么會導(dǎo)致udp丟包呢,我這里列舉了如下幾點(diǎn)原因:

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

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

            3.發(fā)送的包較大,超過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));

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

            5.發(fā)送的廣播包或組播包在windws和linux下都接收正常,而arm上接收出現(xiàn)丟包。這個還不好解決,我的解決方法是大包切割成大小為1448的小包發(fā)送,每個包之間sleep 1毫秒,雖然笨,但有效。我這里mtu size為1500字節(jié),減去udp包頭8個字節(jié),減去傳輸層幾十個字節(jié),實際數(shù)據(jù)位1448字節(jié)。
            除此之外還可以試試設(shè)置arm操作系統(tǒng)緩沖:
            //設(shè)置mtu size 1500最大
            ifconfig eth0 mtu 1500
            //查看接收緩沖最大和默認(rèn)大小。
            sysctl -A | grep rmem
            //設(shè)置接收緩沖的最大大小
            sysctl -w net.core.rmem_max=1048576
            sysctl -w net.core.rmem_default=1048576
            sysctl -w net.ipv4.udp_mem=1048576
            sysctl -w net.ipv4.udp_rmem_min=1048576

            6,局域網(wǎng)內(nèi)不丟包,公網(wǎng)上丟包。這個問題我也是通過切割小包并sleep發(fā)送解決的。如果流量太大,這個辦法也不靈了。


            總之udp丟包總是會有的,如果出現(xiàn)了用我的方法解決不了,還有這個幾個方法: 要么減小流量,要么換tcp協(xié)議傳輸,要么做丟包重傳的工作

            posted on 2012-09-25 03:25 楊粼波 閱讀(2999) 評論(1)  編輯 收藏 引用 所屬分類: 文章收藏 、網(wǎng)絡(luò)編程

            segui久久国产精品| 久久综合欧美成人| 久久久国产视频| 伊人久久大香线蕉成人| 中文字幕热久久久久久久| 精品永久久福利一区二区 | 久久精品国产亚洲网站| 久久96国产精品久久久| 久久国产精品国产自线拍免费| 91久久国产视频| 亚洲人成网亚洲欧洲无码久久| 久久人人爽爽爽人久久久| 久久国产热这里只有精品| 久久强奷乱码老熟女网站 | 欧美精品福利视频一区二区三区久久久精品 | 久久久这里有精品| 久久96国产精品久久久| 成人久久免费网站| 精品人妻伦一二三区久久| 中文字幕无码免费久久| 久久久无码精品亚洲日韩软件| 日产精品久久久一区二区| 欧美一区二区久久精品| 久久精品综合一区二区三区| AV色综合久久天堂AV色综合在| 久久婷婷国产剧情内射白浆| 久久国产精品波多野结衣AV| 99re久久精品国产首页2020| 亚洲国产精品无码久久98| 亚洲精品无码专区久久同性男| 99久久精品国产一区二区| 久久精品国产亚洲网站| 国产精品99久久久久久人| 国内精品久久人妻互换| 日韩精品久久久久久免费| 人妻无码久久一区二区三区免费| 无码任你躁久久久久久久| 久久精品国产色蜜蜜麻豆| 久久精品成人| 一级a性色生活片久久无| 久久午夜综合久久|