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組播支持

回答

相關問題