Netty学习笔记(七)--- Codec框架

我们知道,在网络中数据都是以字节码的形式来进行传输的,每个网络应用程序都必须定义如何解析在两个节点之间来回传输的原始字节码,以及如何将其和目标应用程序的数据格式做相互转换。编解码器就是用来处理这种逻辑的,它由编码器和解码器两个组件组成,其中编码器负责将消息转换为适合传输的格式,解码器则负责将网络字节流转换回应用程序的消息格式。

Netty提供了编解码器框架,使得编写自定义的编解码器很容易,并且也很容易重用和封装。它提供了一系列实现这两种组件的类,查看这些类的源码会发现:编码器继承自ChannelOutboundHandlerAdapter类,而解码器继承自ChannelInboundHandlerAdapter类,算是ChannelHandler的一种特殊实现,因此我们可以像添加ChannelHandler一样,将多个编解码器链接在一起,以实现自定义的任意负责转换逻辑。下面就分别对两种组件的类进行了解。

解码器

上面也提到了,解码器是ChannelInboundHandlerAdapter的子类,所以它负责将进站消息从一种格式转换为另一种格式,它包括了两种类型:

  • 解码字节到消息:ByteToMessageDecoder;
  • 解码消息到消息:MessageToMessageDecoder。
ByteToMessageDecoder类

通常我们需要将字节解码成消息或者解码成其他的序列化字节,Netty为此提供了一个抽象基类:ByteToMessageDecoder。它提供了两个重要方法,我们可以通过继承它并重写这两个方法,实现符合自身需求的解码逻辑。

/* 
这是你必须实现的唯一抽象方法。decode()方法被调用时将会传入一个包含了传入数据的ByteBuf,以及一个用来添加解码消息的List。对这个方法的调用将会重复进行,直到确定没有新的元素被添加到该List,或者该 ByteBuf中没有更多可读取的字节时为止。然后,如果该List不为空,那么它的内容将会被传递给ChannelPipeline中的下一个ChannelInboundHandler。
*/
protected abstract void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out)
/*
Netty提供的这个默认实现只是简单地调用了decode()方法。当Channel的状态变为非活动时,这个方法将会被调用一次。可以重写该方法以提供特殊的处理。
*/
protected void decodeLast(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) {
    decode(ctx, in, out);
}

假设服务端接收了一个包含简单int的字节流,每个int都需要被单独处理。在这种情况下,你需要从入站 ByteBuf中读取每个int,并将它传递给ChannelPipeline 中的下一个 ChannelInboundHandler。为了解码这个字节流,我们就要扩展ByteToMessageDecoder 类。

// 扩展ByteToMessageDecoder类,重写decode()方法,以将字节解码为特定的格式
public class ToIntegerDecoder extends ByteToMessageDecoder{
    @Override
    protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
        // 检查ByteBuf中是否存在4个以上的字节可读
        if (in.readableBytes() >= 4){
            // 从入站ByteBuf中读取一个int,并将其添加到解码消息的List中
            out.add(in.readInt());
        }
    }
}

在这里插入图片描述

上面的代码中,我们通过继承ByteToMessageDecoder类并重写decode方法,实现了自定义的解码器类:ToIntegerDecoder。它的主要功能是从进站ByteBuf中读取字节并解码为int类型的数据。上图展示了解码器处理数据,然后将解码后的消息传递到ChannelPipeline中的下一个ChannelInboundHandler的过程。

你可能会发现,在调用 readInt()方法前不得不验证所输入的 ByteBuf 是否具有足够的数据有点繁琐。其实Netty提供了另外一个特殊的解码器:ReplayingDecoder。它继承并扩展了ByteToMessageDecoder类,它通过使用一个自定义的ByteBuf实现:ReplayingDecoderByteBuf,包装传入的ByteBuf实现了这一点,其将在内部执行该调用,这样我们就可以不用显式的对其进行验证了。

这里有一个简单的准则:如果使用 ByteToMessageDecoder 不会引入太多的复杂性,那么请使用它;否则,请使用 ReplayingDecoder。

MessageToMessageDecoder类

上面的解码器将字节数据解码为int类型的数据,现在我们需要将这些int类型的数据转换为字符串,这就需要用到将一种消息对象转换为另一种消息对象的解码器:MessageToMessageDecoder。该类是一个抽象类,我们需要继承它并实现自己的解码逻辑。

// 扩展MessageToMessageDecoder类,重写decode()方法,以将消息解码为特定的格式的消息
public class IntegerToStringDecoder extends MessageToMessageDecoder<Integer>{
    @override
    protected void decode(ChannelHandlerContext ctx, Integer msg, List<Object> out) throws Exception{
        // 将消息转换为字符串,并将其添加到解码消息的List中
        out.add(String.valueOf(msg));
    }
}

在这里插入图片描述
通过上面的代码,就可以将int类型的数据转换为String类型,并将其添加到解码消息的List中,通过ChannelHandlerContext流转到后续的ChannelHandler中。

编码器

和解码器正好相反,编码器继承自ChannelOutboundHandlerAdapter,它负责将出站数据从一种格式转换为另一种格式。它也提供了两种抽象类:

  • 将消息编码为消息:MessageToMessageEncoder;
  • 将消息编码为字节:MessageToByteEncoder。
MessageToMessageEncoder类

上面的IntegerToStringDecoder类将int类型的数据转换为String类型数据,现在将该数据通过编码器再次转换为int类型数据(当然也可以通过解码器进行转换),这里我们通过继承MessageToMessageEncoder类实现。

// 扩展MessageToMessageEncoder类,重写encode()方法,以将消息编码为特定的格式的消息
public class StringToIntegerEncoder extends MessageToMessageEncoder<String> {
    @Override
    protected void encode(ChannelHandlerContext ctx, String msg, List<Object> out) throws Exception {
        // 将字符串数据解析为int类型数据,并添加到编码消息的list中
        out.add(Integer.parseInt(msg));
    }
}
MessageToByteEncoder类

StringToIntegerEncoder将字符串编码为int类型后,数据继续向下传递,我们再次进行再次编码,将int类型的数据编码为字节数据,这里我们通过继承MessageToByteEncoder类来实现。

// 扩展MessageToByteEncoder类,重写encode()方法,以将消息编码为字节类型
public class IntegerToByteEncoder extends MessageToByteEncoder<Integer>{
    @Override
    protected void encode(ChannelHandlerContext ctx, Integer msg, ByteBuf out) throws Exception {
        // 将int类型的数据写入到ByteBuf中,ByteBuf中数据以字节形式存在
        out.writeInt(msg);
    }
}

通过两个编码器的实现,最终会将字符串类型的数据转换为字节数据,实现了和解码器完全相反的逆操作。

你可能已经注意到了,编码器的类只有一个encode()方法,而解码器有decode()和decodeLast()方法。原因是解码器通常需要在Channel 关闭之后产生最后一个消息,因此也就有了 decodeLast()方法。这显然不适用于编码器的场景——在连接被关闭之后仍然产生一个消息是毫无意义的。

编解码器

我们在编码的过程中,总是将不同功能的组件写入到不同的模块中,以提高代码的可重用性和可扩展性,这也是Netty设计的一个基本原则。就像上面的解码器和编码器,我们把它们当作单独的组件进行讨论,但有时可能将二者结合起来处理数据也很有用,Netty的抽象编解码类正好就是用于这个目的。

ByteToMessageCodec类

ByteToMessageCodec既能处理解码进站数据,也能编码出站数据,因为它结合了ByteToMessageDecoder 以及它的逆向:MessageToByteEncoder。查看源码可看出,它最终同时实现了ChannelInboundHandler和ChannelOutboundHandler两个接口,其内部包裹了MessageToByteEncoder和ByteToMessageDecoder的实现类。

public abstract class ByteToMessageCodec<I> extends ChannelDuplexHandler {
    ......
    // 调用内部类实现赋值
    private final MessageToByteEncoder<I> encoder;

    private final ByteToMessageDecoder decoder = new ByteToMessageDecoder() {
        @Override
        public void decode(...){...}
        @Override
        protected void decodeLast(...){...}
    };
   	......
}
MessageToMessageCodec类

和上面的编解码器类似的,MessageToMessageCodec可以看成是MessageToMessageeEncoder和MessageTomessageDecoder的组合体,它有两个方法需要我们实现。

// 将OUTBOUND_IN类型的消息编码为INBOUND_IN类型的消息,这些消息将被转发到下一个OutBoundHandler
protected abstract void encode(ChannelHandlerContext ctx, OUTBOUND_IN msg, List<Object> out);
// 将INBOUND_IN类型的消息解码为OUTBOUND_IN类型的消息,这些消息将被转发到下一个InBoundHandler
protected abstract void decode(ChannelHandlerContext ctx, INBOUND_IN msg, List<Object> out)
    

它最常见的就是需要将消息从一个API转到另一个API,下面的代码显示了在WebSocket框架APIs之间的消息转换,其中INBOUND_IN类型为WebSocketFrame,OUTBOUND_IN类型为MyWebSocketFrame,后者是编解码器本身的一个静态嵌套类。

public class WebSocketConvertHandler extends MessageToMessageCodec<WebSocketFrame,WebSocketConvertHandler.MyWebSocketFrame>{
    @Override
    // 将MyWebSocketFrame编码为指定的WebSocketFrame子类型
    protected void encode(ChannelHandlerContext ctx, WebSocketConvertHandler.MyWebSocketFrame msg, List<Object> out) throws Exception {
        ByteBuf payload = msg.getData().duplicate().retain();
        switch (msg.getType()){
            case BINARY:
                out.add(new BinaryWebSocketFrame(payload));
                break;
            case TEXT:
                out.add(new TextWebSocketFrame(payload));
                break;
            case CLOSE:
                out.add(new CloseWebSocketFrame(true, 0, payload));
                break;
            case CONTINUATION:
                out.add(new ContinuationWebSocketFrame(payload));
                break;
            case PING:
                out.add(new PingWebSocketFrame(payload));
                break;
            case PONG:
                out.add(new PongWebSocketFrame(payload));
                break;
            default:
                throw new IllegalStateException("Unsupported websocket msg " + msg);
        }
    }
	
    @Override
    // 将WebSocketFrame解码为MyWebSocketFrame类型
    protected void decode(ChannelHandlerContext ctx, WebSocketFrame msg, List<Object> out) throws Exception {
        ByteBuf payload = msg.content().duplicate().retain();
        if (msg instanceof BinaryWebSocketFrame)
            out.add(new MyWebSocketFrame(MyWebSocketFrame.FrameType.BINARY, payload));
        else if(msg instanceof CloseWebSocketFrame)
            out.add(new MyWebSocketFrame(MyWebSocketFrame.FrameType.CLOSE, payload));
        else if (msg instanceof PingWebSocketFrame)
            out.add(new MyWebSocketFrame(MyWebSocketFrame.FrameType.PING, payload));
        else if (msg instanceof PongWebSocketFrame)
            out.add(new MyWebSocketFrame(MyWebSocketFrame.FrameType.PONG, payload));
        else if (msg instanceof TextWebSocketFrame)
            out.add(new MyWebSocketFrame(MyWebSocketFrame.FrameType.TEXT, payload));
        else if (msg instanceof ContinuationWebSocketFrame)
            out.add(new MyWebSocketFrame(MyWebSocketFrame.FrameType.CONTINUATION, payload));
        else
            throw new IllegalStateException("Unsupported websocket msg " + msg);
    }

    public static final class MyWebSocketFrame{
        public enum FrameType{
            BINARY,
           	CLOSE,
            PING,
            PONG,
            TEXT,
            CONTINUATION
        }

        private final FrameType type;
        private final ByteBuf data;

        public MyWebSocketFrame(FrameType type, ByteBuf data){
            this.data = data;
            this.type = type;
        }

        public FrameType getType() {
            return type;
        }

        public ByteBuf getData() {
            return data;
        }
    }
}
CombinedChannelDuplexHandler类

上面的案例中,同一个类中既包含了解码器也包含了编码器,这时就出现了一个问题,如果我只想使用其中的编码器或者解码器,就只能再单独实现一个处理类,其可重用性就大大降低了。Netty提供了一种解决方案,就是使用CombinedChannelDuplexHandler。

public class CombinedChannelDuplexHandler<I extends ChannelInboundHandler, O extends ChannelOutboundHandler> extends ChannelDuplexHandler {
    private I inboundHandler;
    private O outboundHandler;
   	... 
}

它充当了 ChannelInboundHandler 和 ChannelOutboundHandler(该类的类型参数 I 和 O)的容器,通过提供分别继承了解码器类和编码器类的类型,我们可以实现一个编解码器,而又不必直接扩展抽象的编解码器类。

通过上面编写的解码器和编码器,我们可以将它们组合起来构建一个编解码器:

public class CombinedByteIntegerCodec extends CombinedChannelDuplexHandler<ByteToIntegerDecoder,IntegerToByteEncoder>{
    public CombinedByteIntegerCodec(){
        super(new ByteToIntegerDecoder(), new IntegerToByteEncoder());
    }
}

从上面代码可以看出,使用CombinedChannelDuplexHandler绑定解码器和编码器很容易实现,和上面的两种编解码器相比,使用更加简单灵活,提高了代码的可重用性。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值