static_coder的博客

上面只是简单的通过案例介绍了心跳的发送，在实际的应用中，我们需要定义消息的类型，通过类型判断是否为心跳消息，从而区分业务消息和心跳消息。心跳检测的主要实现方式就是在客户端和服务端没有正常数据传输的时间段内，通过发送特定的消息来维持客户端和服务端的连接，而不影响正常的消息处理。对比上面的统一发送心跳，细粒度的就是针对每一个连接定时发送，因为每个客户端连接上来的时间不一致。相比前两的粗暴的发送，这种方式可以避开业务高峰，在需要的时候发送心跳。心跳检测的实现可以用在服务端，也可以用在客户端，当然也可以混用。

是用于检测某个字节 b 的最高位（即第7位，从右往左数）是否为1。如果为1，则返回true，表示数据已经读完。这里正是解决拆包粘包的关键标志位。通信中，所有数据（文本、二进制、控制帧等）都通过帧的形式进行传输。已经自动帮我们解决了拆包和粘包问题，我们一起来看看是怎么解决的！的拆包粘包问题已经妥善解决，开发者只需要配置。，Netty就会在合适的时机自动创建和配置。参数是解决拆包粘包的关键标志位。为我们解决困扰，无需手动处理。协议一样处理拆包和粘包问题。协议数据帧的抽象基类。专门定义了解析帧的字段。

Slf4j@Override// 建立客户端log.info(">>>>Socket客户端建立连接：channelId={}", channel.id());@Override@Override// 断开链接log.info(">>>>Socket客户端断开连接：channelId={}", channel.id());@Override// 接受消息。

Slf4j@Override// 建立客户端log.info("客户端建立连接：channelId={}", channel.id());@Override// 断开链接log.info("客户端断开连接：channelId={}", channel.id());@Override// 接受消息log.info("收到来自通道channelId[{}]发送的消息：{}", channel.id(), msg.text());// 广播通知所有的客户端。

之前分享了关于Socket服务端的代码，这一节我们继续Socket客户端代码的分享。这里要说明的是，自定义的业务处理器需要我们根据需要处理对应的方法。接不接收消息需要根据具体情况处理，案例为了验证客户端和服务端的相互通信，这里选择打印接收的消息。如果还要等待接收服务端的消息，并且会随着方法执行完毕而结束，则需要该代码阻塞。线程池，不过这里的线程组只需要一个就可以了，直接用来处理业务。同时，都需要通过同步的等待端口绑定成功或连接服务端的。为客户端的引导类和服务端是不一样的。关键字的都属于服务端的属性或方法。

消息的编解码，有很多注意点，在搭建过程中，总会不成功， 需要根据连接的协议选择不同的编解码，才能正确的接受和发送信息。如果业务项目比较多，就会出现大量重复的代码，如我们公司就有20多个业务系统。从《代码重构》这本书中，就得知这是一种坏的味道，需要我们想办法优化。长连接是业务项目中经常遇到的技术，往往用于数据向前端推送，如各种大屏、驾驶舱等实时数据的展示。按照阿里程序员的说话，没有什么是加一个中间层不能解决的，如果不能那就再加一层。，我们就需要将服务端的代码复制一份，然后修改成适合自己业务项目的逻辑。

自定义业务处理器是用来处理客户端连接以及消息的。@Slf4j@Override// 建立客户端log.info("Socket客户端建立连接：channelId={}", channel.id());@Override// 断开链接log.info("Socket客户端断开连接：channelId={}", channel.id());@Override// 接受消息。