项目用海思做的编解码卡,发送接收rtp/udp流,有两个bug,一直解决不了,都是和丢包相关的第一个现象是编码卡A和解码卡B搭配使用的时候,log显示丢包,现在已知的情报有:1、测试的环境是A和B之间只有一个交换机,交换机上是只连着A、B还有调试用PC的局域网。
2、在丢包的情况下进行抓包,在解码卡B中用tcpdump抓包,log中显示的丢包和tcpdump中显示的丢包一致,但是利用交换机镜像将发给解码卡B的数据复制到pc上,然后利用wireshark抓包,wireshark显示没有丢包。
3、根据3的现象,我分析包是在解码卡B里丢了, 查看netstat -a 所有的缓冲区都没有堆积的现象
4、cat /proc/net/snmp  没有缓冲溢出和错误造成的丢包
5、ifconfig 判断网卡也没有丢包
6、应用程序中udp缓存设置为10M,系统的缓存最大值也跟着修改了
7、cpu的利用率一直在40%以下
8、关闭所有的log打印,对丢包无改善
9、将程序中recvfrom后面的所有工作全部注释掉,只保留检测丢包,依然丢包好吧,我已经无能为力了。感觉这个包就这么莫名其妙得丢了,现在暂时用的tcp,但是需求上尽可能的还是想用udp,而且解码卡B和其他所有的编码卡配合udp都没有丢包,我感觉是编码器有问题的,但是又和现象3冲突,而且编码卡A都用了好几年了,比我工作年份还多都没收到反馈有这个问题。现象二是编码卡C和解码卡D,也是发送rtp/udp包,直连的情况下,发生丢包,但是中间如果接了一个交换机,就不丢了。以上两个现象,各位大佬如果有遇到过的话,麻烦指导一下小弟啦

解决方案 »

  1.   

    墨菲定理說,一件事如果有可能發生,那麽他就一定會發生。
    udp是無保障協議,丟包不是很正常嗎?
    所以你既然選擇了udp,就應該從應用層面去解決丟包問題。
      

  2.   


    应用层面的解决方法也是有的,但是那么做的话项目上的代价有些大了,不如直接用TCPudp丢包确实是正常的,但是丢包总会有原因吧,我们能不能定位这个包到底是在哪里丢的呢?
    以小弟我的知识来看,现在这个包就是莫名其妙得丢掉了,这莫名其妙得让人很不爽啊
      

  3.   

    個人意見,如果是個非常常見的網絡環境,不要去定位了,定位到也不一定能解決——比如是交換機問題呢?
    udp的設計就是這樣,可以無視丟包的應用最好,可以無視順序的應用解決起來也簡單——確認和重發,絕對比tcp性能好。如果要保證順序,那就tcp吧。話説回來,假設你的環境就是簡單的一對一近距離直連,那用好的網綫並保證雙方的負載都很低的情況下,udp可能基本沒丟包。