Netty in Action笔记(Chapter 7) Codec

最新推荐文章于 2024-10-04 12:09:20 发布

weixin_33711641

最新推荐文章于 2024-10-04 12:09:20 发布

阅读量93

点赞数

文章标签： netty

原文链接：https://segmentfault.com/a/1190000002588171

版权

【7.1 codec】
Whenever you write a network-based program, youll need to implement some kind of codec. The codec defines how the raw bytes need to be parsed and converted to some kind of logic unit that represents a custom message. The same is true for converting the message back to raw bytes that can be transmitted back over the network.

As mention in Chapter 5 and Chapter 6 you need to take special care about message because of reference counting which may be used. For Decoder and Encoder the contract is quite simple. Once a message is decoded or decoded it is automatically released via ReferenceCountUtil.release(message). If you want to explicit not release the message as you may need to keep a reference for later usage etc you need to call ReferenceCountUtil.retain(message). This will make sure the reference count is incremented and so the message not released.

【7.2 Decoders】
Netty provides a rich set of abstract base classes that help you easily write decoders. These are divided into different types:

Decoders that decode from bytes to message
Decoders that decode from message to message
Decoders that decode from message to bytes

Because a decoder handles inbound data, its an abstract implementation of ChannelInboundHandler.

You can put as many decoders in the ChannelPipeline as you need, thanks to the design of the ChannelPipeline, which allows you to assemble your logic of reusable components.

【7.2.1 ByteToMessageDecoder】

But you may have noticed one little thing that is sometimes annoying. You need to check if there are enough bytes ready to read on the input ByteBuf before you do the actual read operation.
For a more complex example, please refer to the LineBasedFrameDecoder. This is part of Netty itself and can be found in the io.netty.handler.codec package.

【7.2.2 ReplayingDecoder】
It does this by wrapping the input ByteBuf with a special implementation that checks if theres enough data ready and, if not, throws a special Signal that it handles internally to detect it. Once such a signal is thrown, the decode loop stops.

Because of this wrapping, ReplayingDecoder comes with some limitations:
- Not all operations on the ByteBuf are supported, and if you call an unsupported operation, it will throw an UnreplayableOperationException.
- ByteBuf.readableBytes() wont return what you expect most of the time.

If you can live with the listed limitations, you may prefer the ReplayingDecoder to the ByteToMessageDecoder. The rule of thumb is, if you can use the ByteToMessageDecoder without introducing too much complexity, do it. If this isnt the case, use the ReplayingDecoder.