Netty入门(九)netty入站与出站机制

最新推荐文章于 2024-06-06 15:22:15 发布
最新推荐文章于 2024-06-06 15:22:15 发布
阅读量1.7k 收藏 8
点赞数
分类专栏： 网络编程
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_42412601/article/details/106958919
版权

目录

基本说明

  • netty的组件设计：Netty的主要组件有Channel、EventLoop、ChannelFuture、ChannelHandler、ChannelPipe等
  • ChannelHandler充当了处理入站和出站数据的应用程序逻辑的容器。例如，实现ChannelInboundHandler接口（或ChannelInboundHandlerAdapter），你就可以接收入站事件和数据，这些数据会被业务逻辑处理。当要给客户端发送响应时，也可以从ChannelInboundHandler冲刷数据。业务逻辑通常写在一个或者多个ChannelInboundHandler中。ChannelOutboundHandler原理一样，只不过它是用来处理出站数据的
  • ChannelPipeline提供了ChannelHandler链的容器。以客户端应用程序为例，如果事件的运动方向是从客户端到服务端的，那么我们称这些事件为出站的，即客户端发送给服务端的数据会通过pipeline中的一系列ChannelOutboundHandler，并被这些Handler处理，反之则称为入站的。如果以服务端为例，出站就是事件的运动方向服务端到客户端，因为对服务端来说，数据是往外流出的，入站就是客户端到服务端。头部那一端为服务端，尾端为客户端。

在这里插入图片描述

编码解码器

  • 当Netty发送或者接受一个消息的时候，就将会发生一次数据转换。入站消息会被解码：从字节转换为另一种格式（比如java对象）；如果是出站消息，它会被编码成字节。
  • Netty提供一系列实用的编解码器，他们都实现了ChannelInboundHadnler或者ChannelOutboundHandler接口。在这些类中，channelRead方法已经被重写了。以入站为例，对于每个从入站Channel读取的消息，这个方法会被调用。随后，它将调用由解码器所提供的decode()方法进行解码，并将已经解码的字节转发给ChannelPipeline中的下一个ChannelInboundHandler。
  • 解码器-ByteToMessageDecoder
    • 关系继承图
      -在这里插入图片描述
    • 由于不可能知道远程节点是否会一次性发送一个完整的信息，tcp有可能出现粘包拆包的问题，这个类会对入站数据进行缓冲，直到它准备好被处理.
    • 一个关于ByteToMessageDecoder实例分析
public class ToIntegerDecoder extends ByteToMessageDecoder {
    @Override
    protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
        if (in.readableBytes() >= 4) {
            out.add(in.readInt());
        }
    }
}

说明：
这个例子，每次入站从ByteBuf中读取4字节，将其解码为一个int，然后将它添加到下一个List中。当没有更多元素可以被添加到该List中时，它的内容将会被发送给下一个ChannelInboundHandler。int在被添加到List中时，会被自动装箱为Integer。在调用readInt()方法前必须验证所输入的ByteBuf是否具有足够的数据
decode 执行分析图 [示意图]
在这里插入图片描述

Handler调用链机制

使用自定义的编码器和解码器来说明Netty的handler 调用机制

  • 客户端发送long -> 服务器
  • 服务端发送long -> 客户端

客户端发送long -> 服务器

服务端代码

服务端：

public class MyServer {
    public static void main(String[] args) {
        NioEventLoopGroup bossGroup = new NioEventLoopGroup(1);
        NioEventLoopGroup workerGroup = new NioEventLoopGroup();

        try{
            ServerBootstrap serverBootstrap = new ServerBootstrap();
            serverBootstrap.group(bossGroup,workerGroup)
                    .channel(NioServerSocketChannel.class)
                    .childHandler(new MyServerInitializer());
            ChannelFuture sync = serverBootstrap.bind(8003).sync();
            sync.channel().closeFuture().sync();
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            bossGroup.shutdownGracefully();
            workerGroup.shutdownGracefully();
        }
    }
}

ChannelInitializer：

public class MyServerInitializer extends ChannelInitializer<SocketChannel> {
    @Override
    protected void initChannel(SocketChannel channel) throws Exception {
        ChannelPipeline pipeline = channel.pipeline();

        //入站的handler进行解码 MyByteToLongDecoder
        pipeline.addLast(new MyByteToLongDecoder());
        //自定义的handler,处理业务逻辑
        pipeline.addLast(new MyServerHandler());
    }
}

入站的解码编码器：将byte解码为long，为啥不用while呢？下面有解释。

public class MyByteToLongDecoder extends ByteToMessageDecoder{
    //上下文channelHandlerContext
    //入站的ByteBuf
    //List集合，将解码后的数据传给下一个handler
    @Override
    protected void decode(ChannelHandlerContext channelHandlerContext, ByteBuf byteBuf, List list) throws Exception {
        System.out.println("MyByteToLongDecoder被调用");
        //因为long8字节,8个字节，才能读取一个long
        if (byteBuf.readableBytes()>=8){
            list.add(byteBuf.readLong());
        }
    }
}

自定义handler：

public class MyServerHandler extends SimpleChannelInboundHandler<Long> {
    @Override
    protected void channelRead0(ChannelHandlerContext channelHandlerContext, Long aLong) throws Exception {
        System.out.println("从客户端"+channelHandlerContext.channel().remoteAddress()+" 读取到long "+aLong);
    }
    @Override
    public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
        cause.printStackTrace();
        ctx.close();
    }
}
客户端代码

客户端：

public class MyClient {
    public static void main(String[] args) {
        NioEventLoopGroup eventExecutors = new NioEventLoopGroup();
        try{
            Bootstrap bootstrap = new Bootstrap();
            bootstrap.group(eventExecutors)
                    .channel(NioSocketChannel.class)
                    .handler(new MyClientInitializer());
            ChannelFuture sync = bootstrap.connect("127.0.0.1", 8003).sync();
            sync.channel().closeFuture().sync();
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            eventExecutors.shutdownGracefully();
        }
    }
}

ChannelInitializer：

public class MyClientInitializer extends ChannelInitializer<SocketChannel> {
    @Override
    protected void initChannel(SocketChannel ch) throws Exception {
        ChannelPipeline pipeline = ch.pipeline();
        //加入出站编码handler
        pipeline.addLast(new MyLongToByteEncoder());
        //加入一个自定义的handler
        pipeline.addLast(new MyClientHandler());
    }
}

出站编码handler：将Long转成byte

public class MyLongToByteEncoder extends MessageToByteEncoder<Long> {
    //编码方法
    @Override
    protected void encode(ChannelHandlerContext ctx, Long msg, ByteBuf out) throws Exception {
        System.out.println("MyLongToByteEncoder encoder 被调用");
        System.out.println("msg="+msg);
        out.writeLong(msg);
    }
}

自定义handler：用ChannelOutboundHandlerAdapter 更合适？

public class MyClientHandler extends SimpleChannelInboundHandler<Long> {
    //通道就绪时，发送数据
    @Override
    public void channelActive(ChannelHandlerContext ctx) throws Exception {
        System.out.println("MyClientHandler 发送数据");
        ctx.writeAndFlush(123465L);
    }
}
测试

启动服务端和客户端。
服务端:

MyByteToLongDecoder被调用
从客户端/127.0.0.1:53198 读取到long 123465

客户端：

MyClientHandler 发送数据
MyLongToByteEncoder encoder 被调用
msg=123465

总结：
从打印日志看出
对于客户端是出站，处于尾部，因此是先调用的自定义的handler,MyClientHandler ,然后才是调用出站编码handler。
即MyLongToByteEncoder <---MyClientHandler。
对于服务端是入站，处于头部，因此先调用解码，然后才执行自定义handler。
即MyServerHandler <----MyByteToLongDecoder

两个细节问题

1.问题1，如果客户端自定义的handler发送的是下面这个代码，数据是16个字节，那么服务端的入解码器的decode方法会被调用几次？

    public void channelActive(ChannelHandlerContext ctx) throws Exception {
        System.out.println("MyClientHandler 发送数据");
//        ctx.writeAndFlush(123465L);
        //abcdabcdabcdabcd是16个字节
        ctx.writeAndFlush(Unpooled.copiedBuffer("abcdabcdabcdabcd", CharsetUtil.UTF_8));
    }

对于decode方法会根据接收到的数据，被调用多次，直到确定没有新的元素被添加到list或者是ByteBuf没有更多的可读字节为止。如果list不为空，就会将list内容传递给下一个ChannelInboundhandler处理，改处理器的方法也会被调用多次。
这里"abcdabcdabcdabcd"是16个字节，所以服务端解码的时候decode会被调两次，每次解码出来的数据放到list里面，list的里数据传给自定义的handler进行处理。

2.使用问题1的代码片段后，发现，客户端的出站编码handler-》MyLongToByteEncoder，没有被调用，怎么回事呢？
对于客户端的自定义handler的前一个handler是MyLongToByteEncoder，MyLongToByteEncoder父类MessageToByteEncoder有一个write方法：

public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
    ByteBuf buf = null;
    try {
    //判断数据是不是应该处理的类型，是的话调用encode方法，进行编码，不是，就不编码，直接write,然后交给前一个handler
        if (acceptOutboundMessage(msg)) {
            @SuppressWarnings("unchecked")
            I cast = (I) msg;
            buf = allocateBuffer(ctx, cast, preferDirect);
            try {
            	//我们写子类的时候，重写了改方法
                encode(ctx, cast, buf);
            } finally {
                ReferenceCountUtil.release(cast);
            }

            if (buf.isReadable()) {
                ctx.write(buf, promise);
            } else {
                buf.release();
                ctx.write(Unpooled.EMPTY_BUFFER, promise);
            }
            buf = null;
        } else {
            ctx.write(msg, promise);
        }

因此，我们编写的Encoder是要注意传入的数据类型和处理的数据类型一致

服务端发送long -> 客户端

基于客户端发送long -> 服务器，再实现服务端发送long -> 客户端。
原理图：
在这里插入图片描述

服务端

ChannelInitializer：
在这里插入图片描述

 //出站的handler进行编码 MyLongToByteEncoder
 pipeline.addLast(new MyLongToByteEncoder());

自定义handler修改：

    protected void channelRead0(ChannelHandlerContext channelHandlerContext, Long aLong) throws Exception {
        System.out.println("从客户端"+channelHandlerContext.channel().remoteAddress()+" 读取到long "+aLong);
        //给客户端发送一个long
        channelHandlerContext.writeAndFlush(98765L);
    }
客户端

ChannelInitializer：
在这里插入图片描述

//加入入站解码handler
pipeline.addLast(new MyByteToLongDecoder());

自定义handler修改：

@Override
protected void channelRead0(ChannelHandlerContext ctx, Long msg) throws Exception {
    System.out.println("服务器的ip="+ctx.channel().remoteAddress());
    System.out.println("收到服务器消息="+msg);
}
    //发送数据
@Override
public void channelActive(ChannelHandlerContext ctx) throws Exception {
    System.out.println("MyClientHandler 发送数据");
    ctx.writeAndFlush(123465L);
    //abcdabcdabcdabcd是16个字节
//        ctx.writeAndFlush(Unpooled.copiedBuffer("abcdabcdabcdabcda", CharsetUtil.UTF_8));
}
测试

启动服务端和客户端。
客户端：
在这里插入图片描述
服务端：
在这里插入图片描述

结论

  • 不论解码器handler 还是 编码器handler 即接收的消息类型必须与待处理的消息类型一致，否则该handler不会被执行
  • 在解码器 进行数据解码时，需要判断 缓存区(ByteBuf)的数据是否足够 ，否则接收到的结果会期望结果可能不一致

其他常用的编解码器

解码器-ReplayingDecoder

public abstract class ReplayingDecoder<S> extends ByteToMessageDecoder
  • ReplayingDecoder扩展了ByteToMessageDecoder类，使用这个类，我们不必调用readableBytes()方法。参数S指定了用户状态管理的类型，其中Void代表不需要状态管理
  • 应用实例：使用ReplayingDecoder 编写解码器，对前面的案例进行简化 [案例演示]
public class MyByteToLongDecoder2 extends ReplayingDecoder<Void> {
    @Override
    protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
        System.out.println("MyByteToLongDecoder被调用");
        //在ReplayingDecoder不需要判断数据是否足够读取，内部会进行处理判断
        out.add(in.readLong());

    }
}

测试：使用MyByteToLongDecoder2 替代之前的MyByteToLongDecoder，结果和之前的一样。

它有一些局限性：

  • 并不是所有的 ByteBuf 操作都被支持，如果调用了一个不被支持的方法，将会抛出一个UnsupportedOperationException。
  • ReplayingDecoder 在某些情况下可能稍慢于ByteToMessageDecoder，例如网络缓慢并且消息格式复杂时，消息会被拆成了多个碎片，速度变慢

其它解码器

  • LineBasedFrameDecoder：这个类在Netty内部也有使用，它使用行尾控制字符（\n或者\r\n）作为分隔符来解析数据。
  • DelimiterBasedFrameDecoder：使用自定义的特殊字符作为消息的分隔符。
  • HttpObjectDecoder：一个HTTP数据的解码器
  • LengthFieldBasedFrameDecoder：通过指定长度来标识整包消息，这样就可以自动的处理黏包和半包消息。

其它编码器

在这里插入图片描述

weixin_42412601
关注
  • 0
    点赞
  • 踩
  • 8
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
Netty工作笔记0073---Neety的出站和入站机制
添柴程序猿的专栏
09-25 370
技术交流QQ群【JAVA,C++,Python,.NET,BigData,AI】：170933152 道理是这样的,如果数据进入客户端是入站, 出客户端 是出站,然后对于服务器来说也是一样的. 入站到客户端解码 出站到服务器需要编码 去看看,比如客户端这里发送数据到服务器的时候,因为这个是出站,所以这个时候要编码 可以看到这里的这个编码器就是个handler,是个outboundHnalerAdapter. 那么服务器发送数据到客户端的时候,入站,需要解码 这里解码也
【netty】netty的pipeline理解
热门推荐
热爱技术，享受生活
12-15 1万+
Netty 的 Pipeline 是一种非常重要的概念，它负责对 Channel 上的事件进行处理，并提供了一种灵活的扩展机制。整个 Pipeline 的处理流程就像一个工厂的生产线一样，每个 Handler 扮演着不同的角色。Pipeline 是 Netty 中非常重要的一个组件，它通过灵活的 Handler 链式处理机制实现了高效、稳定、可扩展的网络编程。Pipeline 由一系列的 Handler 组成，Handler 通常会被添加到 Pipeline 中，从而形成一个有序的 Handler 链。
Netty入门 - Netty入站与出站机制
最新发布
qq_33240556的博客
06-06 358
入站处理器用于处理从远程对等方接收到的数据或事件。出站处理器用于处理要发送到远程对等方的数据或事件。ChannelPipeline 是一系列处理器的链，负责处理数据的流动。通过合理地使用入站和出站处理器，您可以在 Netty 中构建强大和灵活的网络应用程序。
Java基础之《netty（24）—netty入站与出站机制》
csj50的专栏
01-16 614
例如，实现ChannelInboundHandler接口（或ChannelInboundHandlerAdapter），你就可以接收入站事件和数据，这些数据会被业务逻辑处理。ChannelOutboundHandler原理一样，只不过它是用来处理出站数据的。1、netty的组件设计：netty的主要组件有Channel、EventLoop、ChannelFuture、ChannelHandler、ChannelPipe等。2、ChannelHandler充当了处理入站和出站数据的应用程序逻辑的容器。
netty的出站入站梳理
Brave_heart4pzj的博客
07-18 322
https://www.jianshu.com/p/0bd66bd460e4 https://www.jianshu.com/p/01b9b8cff943 https://blog.csdn.net/qq_34827263/article/details/100729528
关于Netty Handler入站出站机制详解
qq_26702635的博客
06-28 952
关于Netty Handler入站出站机制详解 引言 由于工作需要，我开始对Netty这套框架进行了研究及使用，在学习过程中发现各论坛对Handler的入站出站机制都存在一个错误，所以写了这篇文章，方便自己及其他网友参阅。 1.Netty PipeLine机制解释 众所周知，Netty是通过Channel来建立连接的，并且这个Channel在java原生NIO Channel的基础上改装优化的。 每当一个新的连接建立后，Netty都会生成一个Channel及一个Pipeline，并互相引用； 这个Pipe
Netty——聊天室/入站和出战
qq_41157876的博客
12-18 232
聊天室实现 实验过程 过程分析 入站和出战 1. 聊天室实现 服务端启动类：MyChatServer import io.netty.bootstrap.ServerBootstrap; import io.netty.channel.ChannelFuture; import io.netty.channel.EventLoopGroup; import io.netty.channel.nio.NioEventLoopGroup; import io.netty.channel..
Netty 入门与实战：仿写微信 IM 即时通讯系统
06-26
这将使得整个系统的配置更加简洁，同时也方便与其他Spring生态组件如WebSocket、RabbitMQ等进行集成。 对于IM系统，我们需要实现用户注册、登录验证、好友关系管理、消息发送和接收、群组管理等功能。这涉及到...
Netty入门与实战：仿写微信IM即时通讯系统
01-12
### Netty入门与实战：仿写微信IM即时通讯系统 #### 一、引言 随着移动互联网技术的飞速发展，即时通讯(IM)系统已成为人们日常生活中不可或缺的一部分。微信作为国内最受欢迎的即时通讯软件之一，其高效稳定的通信...
Netty 入门与实战
12-04
文件"16实战：群聊的发起与通知.html"可能讲述了如何在Netty架构下创建群聊并通知所有成员，涉及到的消息分发和通知机制。 10. **客户端互聊原理与实现** 文件"15实战：客户端互聊原理与实现.html"可能涵盖了...
Netty 入门与实战：仿写微信 IM 即时通讯系统.zip
02-26
《Netty 入门与实战：仿写微信 IM 即时通讯系统》是一本深入浅出的教程，旨在帮助读者掌握使用Netty构建高效、稳定、高性能的即时通讯系统的方法。通过模仿微信IM的实现，本书将理论知识与实践案例相结合，使读者...
并发编程 | Netty - [出站、入站机制]
ZEUS00456的专栏
10-16 795
并发编程 | Netty - [出站、入站机制]
Netty的入站出站与自定义编解码器
jym的博客
02-12 8546
入站出站 ChannelPipeline 提供了ChannelHandler链的容器，以客户端应用程序为例，如果事件的运动方向是从客户端到服务端，称之为出站，即客户端发送给服务端的数据会通过pipeline中的一系列ChannelOutboundHandler，并被这些handler处理，反之则成为入站 编码解码器 1.当netty发送或者接受一个消息的时候，就将会发生一次数据转换，入站消息会被解...
Netty各组件基本用法、入站和出站详情、群聊系统的实现、粘包和拆包
m0_62434717的博客
07-31 473
Netty用于处理高并发的实用框架
11.netty入站与出站（处理器链调用机制）
PacosonSWJTU的博客
09-10 1802
1.本文源代码总结自 B站《netty-尚硅谷》；2.本文部分内容总结自。
Netty入门
w
05-01 1793
一、Netty介绍Netty是目前最流行的NIO框架之一，Netty屏蔽了NIO通信的底层细节，在和用户交互的边界做了封装。可以使用Netty作为底层通信框架，也可以用来构建高性能的异步通信能力。Netty的核心核心组件： 一、Channel 二、回调 三、Future 四、事件和ChannelHandler 这些构建代表了不同类型的构造：资源、逻辑以及通知。你的应用程序将使用它们来访问网
Netty专栏——出入站机制
御承扬的博客
01-15 356
Netty 框架的出入站机制
netty入门（十九）Netty入站与出站机制
zhufei463738313的博客
03-10 523
ChannelPipeline 提供了 ChannelHandler 链的容器。以客户端应用程序为例，如果事件的运动方向是从客户端到服务端的，那么我们称这些事件为出站的，即客户端发送服务端的数据会通过 pipeline 中的一系列 ChannelOutboundHandler，并被这些 Handler 处理，反之则称为入站的
Netty 出站入站机制详解
Dennis学习小站
05-03 4250
前段时间在B站学习Netty，讲到出站入站的机制时一直没搞明白到底是怎么弄的，直到开始讲源码部分时才终于搞明白。 先来看看Netty官方有关出站入站机制的解释： 按照图片的理解，则是在通道中，每次出现读事件时，会从头至尾依次调用Inbound即入站方法处理； 而触发写事件时，则会从尾到头依次调用outbound即出站方法处理。 这里会给人一种错觉，那就是netty在内部维护了两个单向链表实现出站...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值