有 Java 编程相关的问题?

你可以在下面搜索框中键入要查询的问题!

java Netty自适应UDP多播支持

新手在使用Netty 3.2.4处理UDP视频流时遇到问题。在不同的机器上,我们看到使用Netty删除的字节等。在Netty获得字节后,我们有一个小计数器,以查看接收到多少字节。这种差异不仅仅是UDP不可靠性的原因。在本例中,我们还将字节保存到文件中以播放视频。在VLC中播放视频确实说明了丢失的字节。(发送的数据包大小约为1000字节)

问题

  • 就不能使用AdaptiveReceiveBufferSizePredictor for UDP流侦听器而言,我们对Netty API的假设是否正确
  • 我们看到的行为有更好的解释吗
  • 有更好的解决办法吗?有没有办法在UDP中使用自适应预测器

我们已经尝试过的

...
DatagramChannelFactory datagramChannelFactory = new OioDatagramChannelFactory(
                                                Executors.newCachedThreadPool());
connectionlessBootstrap = new ConnectionlessBootstrap(datagramChannelFactory);
...
datagramChannel = (DatagramChannel) connectionlessBootstrap.bind(new 
                  InetSocketAddress(multicastPort));
datagramChannel.getConfig().setReceiveBufferSizePredictor(new   
                FixedReceiveBufferSizePredictor(2*1024*1024));
...
  • 从文档和谷歌搜索中,我认为正确的方法是使用OioDatagramChannelFactory而不是NioDatagramChannelFactory

  • 此外,虽然我找不到明确的声明,但您只能将FixedReceiveBufferSizePredictor与OioDatagramChannelFactory一起使用(vs AdaptiveReceiveBufferSizePredictor)。通过查看源代码,我们发现AdaptiveReceiveBufferSizePredictor的previousReceiveBufferSize()方法不是从OioDatagramWorker类调用的(而它是从NioDatagramWorker调用的)

  • 因此,我们最初将FixedReceivedBufferSizePredictor设置为(2*1024*1024)

观察到的行为

  • 在不同的机器上运行(不同的处理能力),我们看到Netty接收的字节数不同。在我们的例子中,我们通过UDP传输视频,并且我们能够使用流字节的回放来诊断读取的字节的质量(发送的数据包大小约为1000字节)

  • 然后,我们对不同的缓冲区大小进行了实验,发现1024*1024似乎可以让事情变得更好。。。但真的不知道为什么

  • 在研究FixedReceivedBufferSizePredictor的工作原理时,我们意识到它只是在每次数据包进入时创建一个新的缓冲区。在我们的例子中,它将创建一个2*1024*1024字节的新缓冲区,无论数据包是1000字节还是3MB。我们的数据包只有1000字节,所以我们认为这不是我们的问题。这里的任何逻辑都可能导致性能问题吗?例如,每次数据包进入时缓冲区的创建

我们的解决方案

然后,我们考虑了使缓冲区大小动态的方法,但意识到我们不能像上面提到的那样使用AdaptiveReceiveBufferSizePredictor。我们实验并创建了自己的MyAdaptiveReceiveBufferSizePredictor,以及附带的MyIODatagramChannel工厂、*通道、*通道工厂、*PipelineSink、*工作类(最终称为MyAdaptiveReceiveBufferSizePredictor)。预测器只需根据最后一个数据包大小将缓冲区大小更改为缓冲区大小的两倍或减小缓冲区大小。这似乎改善了情况


共 (1) 个答案

  1. # 1 楼答案

    不确定是什么导致了性能问题,但我发现this thread
    这可能是因为为每个传入数据包创建了ChannelBuffers,在这种情况下,您必须等待Milestone 4.0.0