如何在Netty 4中添加头部和尾部分隔符帧解码器？

-1

我刚刚开始编码Netty 4，发现它似乎只支持单数分隔符，即使它声称支持多个分隔符。事实是，它支持交替使用多个分隔符，而不是同时使用。如何在Netty 4中添加头部和尾部分隔符帧解码器？

为什么我需要头部和尾部分隔符的原因是为了在发生包丢失或无序包接收情况下的速度。例如我的框架看起来像这样：$ _ {LEN} {DATA} \ r \ n

所以我的头部分隔符是$ _，而尾部分隔符是\ r \ n。

假设在一帧中接收到多个数据包，而一些中间数据包在传输期间丢失，如果没有$ ，解码器必须继续搜索\ r \ n以确定结束。如果\ r \ n也丢失了，那么它必须搜索下一个\ r \ n而不是击中导致新消息的$ ...

但是现在的Netty DelimiterBasedFrameDecoder似乎无法支持我想上面。我应该如何实现这个目的？

它看起来对我来说Netty FrameDecoder设计没有考虑到数据包丢失或打包器无序的情况？对Netty来说，我可能是错的。如果有人能够告诉我这件事，请予以谅解。

来源

2016-05-23 Richard Chen

你使用udp或tcp流吗？在udp流中，您通常不会重新分配接收到的字节 – Ferrybig

tcp streams：服务器在云端数据中心运行，客户端设备通过WiFi LAN或3G/2G SIM移动无线广域网连接。因此，网络可能不稳定，容易受到网络干扰，通常会导致数据包丢失... –

请注意，tcp可以保证您的数据是原样（因此无需修改）或连接错误。这意味着数据包的任何部分都不会丢失。 – Ferrybig

为了简洁和高效，我最终使用Netty的LengthFieldBasedFrameDecoder来处理客户端和服务器端数据包帧解码。我的消息是这种格式：\ r \ n $的LEN $ DATA \ r \ n $的LEN $ DATA

ChannelPipeline p = ch.pipeline(); 
p.addLast(new LengthFieldBasedFrameDecoder(1024,2,4,0,6));

根据不同的客户端环境，Netty的图书馆可能会或可能不会在客户端的连接和通信应用。但是通过这种消息结构，在编写相对健壮和高效的帧解码代码时总是可以轻松实现。

来源

2016-05-24 01:12:46

'LengthFieldBasedFrameDecoder'是正确的选择 – user5698801

我认为DelimiterFrameDecoder假定了一个无损的有序输入流。如果您的管道中的低层传输层不是无损的有序连接，那么您需要实现自己的帧解码器，通过实施校验和和帧ID或其他协议策略来处理丢失的数据和乱序帧。

来源

2016-05-23 15:22:42 Mike

在嘈杂的无线网络环境中，数据包丢失或无序可能非常普遍。但我认为Netty中提供的DelimiterFrameDecoder或其他分隔符帧解码器支持恢复（我的意思是最终能够找到正确的开始数据包）来自混合了损坏或丢失字节的传入字节流。这些解码器与我之间的主要区别在于它的效率：1）快速定位新的良好起始数据包; 2）获得良好数据包浪费更少的字节;但是我用LengthFieldBasedFrameDecoder发现了一个更简单的方法。 –

此外，对于数据包损坏或丢失，我实现了应用级逻辑，通过依靠来自接收方的ACK消息来执行有保证的消息传递。当然，消息必须在接收到ACK之前缓存，并且在接收到ACK之后将被删除。 –

如何在Netty 4中添加头部和尾部分隔符帧解码器？

回答

相关问题