Netty的深入浅出--81.自定义编解码器简单实例

我们一些一个程序来实现自定义编解码器

客户端handler

服务端

现在服务端如何从客户端接收long类型数据呢？

方法很简单，在我们最后这个处理器前面增加编解码处理器。也就是我们这个程序的目的，创建自定义编解码处理器。

在netty中给我们提供了一个顶层的编解码处理器

要实现解码处理器，我们只需要实现它的decode方法 

  decode方法的doc文档

然后我们往回看

从bytebuf的in里面读数据，然后放入到集合out里面

 

 在这里为什么要进行frame detection呢

主要是解决TCP粘包问题

TCP粘包：由客户端发送过来的数据可能会出现两条信息粘在一起，这样的话直接读取是会出现问题的。

拆包：将一条很长的tcp传输过程来信息进行拆开处理 

 创建自定义解码器，至于为什么要判断，一定要考虑清楚哦，不懂看上一篇博客

入站处理器以及完成，现在编写出站处理器

出站处理器的顶层抽象处理器是

MessageToByteEncoder里面的encode()方法 

创建自定义编码器 MyLongToByteEncoder

对于编解码处理器来说他们的顺序可以随意，因为它们本身不在一个链上面。 

启动服务端：

启动客户端

客户端输出

服务端输出

流程分析：

服务端收到客户端发送过来的请求，首先经过MyByteToLongDecoder()处理器

所以第一个打印出“decode invoked！”

可写入的long占 8个字节，打印8

然后进入到下一个处理器MyServerHandler()

打印出远程地址以及消息本身

然后写出客户端，进入MyLongToByteEncode()里面

encode()方法被调用

 

分析客户端 

首先由客户端将消息发送过去

 发送完之后进入到MyLongToEncode()里面

打印出相关信息

 

写入到网络通道中，然后服务端收到处理完之后，响应回来，进入到MyByteToLongDecoder()

 

 

又进入到自定义处理器MyClientHandler()中

 

 

我们发现客服端这个时候又写回数据，这样的话，应该会出现死循序， 但是并没有出现

主要原因是它不是long类型，当消息发送给服务端之后，服务端直接丢弃。