Netty5用户手册之五：netty中流数据的传输处理问题

处理流数据的传输

SocketBuffer的警告

在如tcp/ip的以流为基础传输数据中，数据被接收后，被保存在一个socket接收缓冲区中。不幸的是，这个以流为基础的缓冲区buffer不是一个包packet的队列，而是一个字节byte队列。这意味着，即使你发送两个消息message作为2个独立的包，操作以系统不会把他们作为两个消息message，而是仅仅当做一堆字节。因此，无法保证你读到的数据就是对方写的数据，这就是tcp、ip中常见的拆包、粘包问题。例如，假设操作系统已经接收到了三个包，如下：

       由于流传输的这个普通属性，在读取他们的时候将会存在很大的几率，这些数据会被分段成下面的几部分：

       因此，作为一个接收方，不管它是服务端还是客户端，都需要把接收到的数据整理成一个或多个有意义的并且能够被应用程序容易理解的数据。以上面这个例子为例，被接收的数据应该被分段为一下几部分：

要想通过应用程序的方式解决上面提到的，拆分粘包的问题，可以通过以下几个部分来处理：

第一种解决方案

现在，让我回想一下time客户端的示例，我们会遇到相同的问题。一个32位字节的整形数据是一个非常小的数据，并且它也不见得会经常被分段。然而，它确实也会被拆分到不同的数据段中，并且被拆分的可能性会随着传输的增加而增加。

        一种简单的解决方式是创建一个内部积累的缓冲区，并且等待知道4个字节都被接收到这个内部的缓冲区中。下面为修改后的客户端TimeClientHandler实现类代码来修复这个问题：

       

package com.zzj.nio.netty;

import java.util.Date;
import io.netty.buffer.ByteBuf;
import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.ChannelInboundHandlerAdapter;

/**
 * Time客户端处理器类
 * @author zzj
 * @date Oct 19, 2016 5:48:56 PM
 */
public class TimeClientHandler extends ChannelInboundHandlerAdapter {

	private ByteBuf buf;
	
	
	 @Override
	public void handlerRemoved(ChannelHandlerContext ctx) throws Exception {
		buf.release();
		buf = null;
	}

	@Override
	public void handlerAdded(ChannelHandlerContext ctx) throws Exception {
		buf = ctx.alloc().buffer(1);
	}

	@Override
	    public void channelRead(ChannelHandlerContext ctx, Object msg) {
	        ByteBuf m = (ByteBuf) msg; // (1)
	        buf.writeBytes(m);
	        System.out.println("ssss");
	        try {
	           if (buf.readableBytes()>=4) {
	        	   long currentTimeMillis = (buf.readUnsignedInt()-2208988800l)*1000l;
	        	   System.out.println(new Date(currentTimeMillis));
	        	   ctx.close();
	           }
	        } finally {
	            m.release();
	        }
	    }

	@Override
	public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
	   cause.printStackTrace();
       ctx.close();
	}
}

       1.ChannelHandler有两个生命周期监听方法：handlerAdded和handlerRemoved方法，你可以完成任意初始化任务，只要它不会被阻塞很长的时间。

       2.首先，所有被接收到的数据会被积累到buf对象中。

       3.然后，handler处理器必须检测buf是搜包含了足够多的数据，这里个例子中是4个字节，然后去处理实际的业务逻辑。否咋，netty将会重复调用channelRead方法当数据被调用，并且实际上所有的4个字节都会被积累。

第二种解决方案

      尽管第一个解决方案能够解决timeclient可能发生半包粘包的问题，但是修改的那个handler看起来不够干净优雅。想一下，如果存在一个复杂的具有多个字段的协议，比如包含很多很长的字段，ChannelHandler的实现方式将会变得维护可困难。

      可能你已经知道，我们可以为ChannelPipeline添加一个ChannelHandler处理器。因此，我们可以将一个复杂的ChannelHandler拆分成多个单独的处理器来减少系统的复杂性。例如，你可以将TimeClientHandler拆分成两个处理器：

      1.TimeDecoder用来处理半包拆包的问题。

      2.timeClientHandler原始版本的实现.

Netty提供了一个可扩展的类，帮你完成TimeDecoder的开发：

/**
 * TimeClient的编码器
 * @author zzj
 * @date Oct 20, 2016 1:39:38 PM
 */
public class TimeDecoder extends ByteToMessageDecoder {

	/* (non-Javadoc)
	 * @see io.netty.handler.codec.ByteToMessageDecoder#decode(io.netty.channel.ChannelHandlerContext, io.netty.buffer.ByteBuf, java.util.List)
	 */
	@Override
	protected void decode(ChannelHandlerContext arg0, ByteBuf arg1, List