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

            亚洲人成电影网站久久| 久久午夜夜伦鲁鲁片免费无码影视| 久久亚洲sm情趣捆绑调教 | 久久午夜伦鲁片免费无码| 久久亚洲欧美国产精品| 66精品综合久久久久久久| 日本久久中文字幕| 色综合久久久久综合体桃花网 | 久久婷婷色综合一区二区| 亚洲精品97久久中文字幕无码| 伊人久久大香线蕉av一区| 国产精品久久久久AV福利动漫| 久久99精品久久久久久齐齐| 久久青青草视频| 久久久老熟女一区二区三区| 精品久久久久久无码中文字幕 | 99热成人精品热久久669| 亚洲а∨天堂久久精品9966| 久久综合狠狠综合久久综合88 | 久久精品视频一| 久久精品成人国产午夜| 久久人人爽人人爽人人av东京热 | 88久久精品无码一区二区毛片| 亚洲精品午夜国产VA久久成人| 久久国产精品波多野结衣AV| 老色鬼久久亚洲AV综合| 伊人久久亚洲综合影院| 国产福利电影一区二区三区,免费久久久久久久精 | 高清免费久久午夜精品| 久久精品国产亚洲αv忘忧草| 岛国搬运www久久| 国产麻豆精品久久一二三| 狠狠色噜噜色狠狠狠综合久久| 久久精品国产99国产精品| 久久精品国产99国产精品澳门| 久久精品www人人爽人人| 久久久久久曰本AV免费免费| 欧美精品丝袜久久久中文字幕 | 97久久精品无码一区二区 | 国产精品欧美亚洲韩国日本久久 | 伊人久久大香线蕉亚洲五月天 |