Question

新手使用Netty 3.2.4处理UDP视频流时遇到问题。在不同的机器上，我们使用Netty看到丢弃的字节等。在Netty获取字节后，我们有一个小计数器，以查看接收的字节数。方差不仅仅是UDP不可靠性的原因。在我们的例子中，我们还将字节保存到文件中以播放视频。在VLC中播放视频确实说明了丢弃的字节。（发送的数据包大小约为1000字节）。

问题

我们对Netty API的假设是否正确无法使用AdaptiveReceiveBufferSizePredictor进行UDP流监听？
对我们所看到的行为有更好的解释吗？
有更好的解决方案吗？有没有办法使用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));
...

从文档和Google搜索中，我认为正确的方法是使用OioDatagramChannelFactory而不是NioDatagramChannelFactory。
此外，虽然我找不到明确说明，但您只能将FixedReceiveBufferSizePredictor与OioDatagramChannelFactory（vs AdaptiveReceiveBufferSizePredictor）一起使用。我们通过查看源代码并意识到没有从OioDatagramWorker类调用AdaptiveReceiveBufferSizePredictor的previousReceiveBufferSize（）方法（而是从NioDatagramWorker调用它）来发现这一点
因此，我们最初将FixedReceivedBufferSizePredictor设置为（2 * 1024 * 1024）

观察到的行为

在不同的机器上运行（处理能力不同）我们看到Netty采用了不同数量的字节。在我们的例子中，我们通过UDP流式传输视频，我们可以使用流式字节的回放来诊断读入的字节质量（发送的数据包大小约为1000字节）。
然后我们尝试了不同的缓冲区大小，发现1024 * 1024似乎让事情变得更好......但实际上并不知道为什么。
在查看FixedReceivedBufferSizePredictor如何工作时，我们意识到每次数据包进入时它都会创建一个新的缓冲区。在我们的例子中，无论数据包是1000，它都会创建一个2 * 1024 * 1024字节的新缓冲区字节或3 MB。我们的数据包只有1000字节，所以我们认为这不是我们的问题。这里的任何逻辑都可能导致性能问题吗？例如，每次数据包进入时都会创建缓冲区？

我们的解决方法

然后，我们考虑了使缓冲区大小动态化的方法，但意识到我们无法使用上面提到的AdaptiveReceiveBufferSizePredictor。我们实验并创建了我们自己的MyAdaptiveReceiveBufferSizePredictor以及随附的MyOioDatagramChannelFactory，* Channel，* ChannelFactory，* PipelineSink，* Worker类（最终调用MyAdaptiveReceiveBufferSizePredictor）。预测器只是根据最后一个数据包大小将缓冲区大小更改为缓冲区大小的两倍或减少它。这似乎改善了事情。

Answer 1

不确定导致性能问题的原因，但我找到了this thread 这可能是由为每个传入数据包创建ChannelBuffers引起的，在这种情况下，您必须等待Milestone 4.0.0。

Netty自适应UDP多播支持

1 个答案: