• <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丟包呢,我這里列舉了如下幾點原因:

            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ò)編程

            久久综合色老色| 久久精品亚洲精品国产欧美| 精品无码久久久久国产动漫3d| 亚洲国产精品一区二区三区久久| 久久免费看黄a级毛片| 天天久久狠狠色综合| 日韩精品无码久久一区二区三| 久久国内免费视频| 99久久国产热无码精品免费| 久久精品国产第一区二区| 国内精品伊人久久久久777| 91久久精品国产91性色也| 一本色综合网久久| 青青草原综合久久大伊人导航| 热re99久久6国产精品免费| 久久99久久无码毛片一区二区| 久久久久久无码Av成人影院| 久久国产香蕉一区精品| 91精品国产色综合久久| 国产精品成人久久久| 久久国产精品一区| Xx性欧美肥妇精品久久久久久| 久久99热只有频精品8| 国产精品成人久久久| 久久午夜无码鲁丝片午夜精品| 久久亚洲国产午夜精品理论片| 久久亚洲精精品中文字幕| 久久久久波多野结衣高潮| 久久久久久A亚洲欧洲AV冫| 丰满少妇人妻久久久久久4| 久久66热人妻偷产精品9| 久久综合狠狠综合久久| 模特私拍国产精品久久| 欧美精品福利视频一区二区三区久久久精品| 国产精品岛国久久久久| 狠狠88综合久久久久综合网| 人妻久久久一区二区三区| 国产情侣久久久久aⅴ免费| www.久久热.com| 一本久久a久久精品综合夜夜| 亚洲午夜久久影院|