Netty自适应UDP组播支持

使用Netty 3.2.4无法处理UDP视频流的新手们。在不同的机器上，我们看到使用Netty丢弃了字节等。在Netty获取字节后，我们有一个小计数器，看看有多少字节被接收。差异不仅仅是UDP不可靠性所能解释的。在我们的情况下，我们还将字节保存到文件以播放视频。在VLC中播放视频确实说明了丢失的字节。（发送的数据包大小约为1000字节）。Netty自适应UDP组播支持

问题

是我们的Netty的API中不能够使用UDP流侦听AdaptiveReceiveBufferSizePredictor而言正确的假设？
对我们看到的行为有更好的解释吗？
有没有更好的解决方案？有没有办法使用自适应预测器与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）

观测到的行为

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

我们的解决方法

然后我们想到办法，使缓冲区的大小动态的，但认识到，我们不能使用AdaptiveReceiveBufferSizePredictor如上所述。我们尝试和并结合MyOioDatagramChannelFactory一起创建了自己的MyAdaptiveReceiveBufferSizePredictor，*通道，*的ChannelFactory，* PipelineSink，*工人类（即最终调用MyAdaptiveReceiveBufferSizePredictor）。预测器只是根据最后一个数据包大小更改缓冲区大小以加倍缓冲区大小或将其减小。这似乎改善了事情。

来源

2012-02-01 Sam P.

不正确的不确定是什么原因导致的性能问题，但我发现this thread。
它可能通过建立ChannelBuffers在这种情况下，你必须等待Milestone 4.0.0每个进入的数据包造成的。

来源

2012-04-23 07:08:15

Netty自适应UDP组播支持

回答

相关问题