Netty笔记：FrameDecoder
? ? ?FrameDecoder是Netty Protocol Decode最关键的Decoder，几乎所有和协议解码相关的Decoder都继承自它，那到底解决了什么问题？为什么需要这样的一个部件呢？TCP的传输是基于流的，每个数据包都有可能被分片和然后重组，这时候我们就需要协议去界定一个数据包，通常来说用来方式来确定数据包的边界，一个是基于长度，简单一点就是规定数据包的长度，例如规定每个数据包的长度为100byte，FixedlengthFrameDecoder就是这样，可实际中我们的数据包并不都是固定长度，可以说是大小不一的情况更常见。怎么样解决这个问题呢？我们加一个长度属性的header，标示我们实际内容的大小，这就是LengthFieldBasedFrameDecoder。
? ? 回归正题，为什么需要FrameDecoder，来考虑两个极端的问题：? ? 1. 假设我们一帧（数据包）的大小为100byte，然而socket的sendBuffer的大小只有50byte，server端的readbuffer的大小也是50byte。这就意味着我们读两次才能读完成一帧。? ? 2.Netty的NioWorker(Poller)是有读写控制，每次只能读到制定大小的buffer，例如一帧的大小还是100byte，Poller读到1024k，然后触发message receive事件去处理，这样第11帧只能读到24byte，显然不是一完整的帧剩余的76byte需要在下一次poll中接收。? ? ?通过这两个问题我们发现，有时候为了读完整的一帧需要累积读多次，就像以上两种情况需要两次，我们不能读到数据就进行处理，我们得需要一个累积器，把分散的buffer累积到累积器中，再进行解码，这样就能避免一帧跨两个buffer。? ? ?还是看看代码吧
if (cumulation == null) { // the cumulation buffer is not created yet so just pass the input to callDecode(...) method 第一次的时候，累积器还没有创建，这时先解码,然后把剩余的部分加到累积器中。如果每次input都变完整的解码成一帧，没有/剩余则不会创建累积器 callDecode(ctx, e.getChannel(), input, e.getRemoteAddress()); //如果有剩余放入累积 if (input.readable()) { // seems like there is something readable left in the input buffer. So create the cumulation buffer and copy the input into it (this.cumulation = newCumulationBuffer(ctx, input.readableBytes())).writeBytes(input); } } else { assert cumulation.readable(); boolean fit = false; int readable = input.readableBytes(); int writable = cumulation.writableBytes(); int w = writable - readable; if (w < 0) { int readerIndex = cumulation.readerIndex(); if (w + readerIndex >= 0) { // the input will fit if we discard all read bytes, so do it cumulation.discardReadBytes(); fit = true; }?