资讯专栏INFORMATION COLUMN

基于 Netty 的可插拔业务通信协议的实现「2」特定业务消息对象的设计

Yuqi / 2026人阅读

摘要:而实际两者之间的通信使用的是基于的自定义二进制数据帧,对象与数据帧之间需进行转换。该类实现了编码解码方法,故可对消息对象进行编码或对数据帧进行解码。该类的静态方法可通过指定功能消息对象生成相应的回复对象。

本文为该系列的第二篇文章,设计需求为:服务端程序和众多客户端程序通过 TCP 协议进行通信,通信双方需通信的消息种类众多。上一篇文章详细描述了该通信协议的二进制数据帧格式以及基本 Java 消息类,假设通信双方「服务端、客户端」均由 Netty 框架构建而成,双方在程序内部使用 Java 消息对象,通信双方信息交互采用的是自定义二进制帧格式,本文通过一个具体实例,探讨指定的 Java 消息对象与其相应的二进制数据帧相互转换的方法。

1 特定 Java 消息对象通信举例

本小节以一个具体的需求为例,讲述该自定义通信协议的工作流程。该需求为:对某一个特定的客户端进行命名。该需求的具体工作流程描述如下:

服务端需主动向指定的客户端发送消息,对客户端设置指定的名称,客户端接到指定的消息并验证合法后,需向服务端反馈消息接受成功的确认回复,服务器接收到该回复后,即可认为对客户端进行命名的消息发送成功并且名字设置成功,若服务端在指定的时间内未收到回复,需进行重发或者向上层「如管理员或数据库」反馈该客户端的异常。

上述过程使用 UML 序列图演示如下:

由上图可以直观地看出:管理员对服务器的操作以及服务器对管理员的反馈均为动作,Server 与 Client 之间的通信以 Java 的视角均通过 Java 消息对象,共需两个对象:客户端别名设置对象、客户端别名设置回复对象。而实际两者之间的通信使用的是基于 TCP 的自定义二进制数据帧,对象与数据帧之间需进行转换。

2 该任务所需 Java 消息类的设计

上小节所述过程需要两个 Java 消息类,如下所示:

客户端别名设置类

/**
 * 「消息对象」客户端别名设置
 */
public class MsgDeviceName extends BaseMsg {

    private final String name;

    public MsgDeviceName(BaseMsgCodec msgCodec, int groupId, int deviceId, String name) {
        super(msgCodec, groupId, deviceId);
        this.name = name;
    }

    public String getName() {
        return name;
    }

    @Override
    public String msgDetailToString() {
        return super.msgDetailToString() + "别名:" + name;
    }
}

客户端别名设置回复类「直接使用通用回复类」

/**
 * 「消息对象」通用消息回复
 */
public class MsgReplyNormal extends BaseMsg {

    public MsgReplyNormal(BaseMsgCodec msgCodec, int groupId, int deviceId) {
        super(msgCodec, groupId, deviceId);
    }

    @Override
    public String msgDetailToString() {
        return super.msgDetailToString();
    }
}

客户端别名设置类相比于基础消息类,覆写了消息细节描述方法,优化调试日志的使用体验。主要改变是,仅仅增加了客户端别名的引用及其 Get 方法;而对于客户端别名设置回复,直接使用了通用回复类,减小了设计的复杂度。

该自定义帧协议有一个设计要点:每一个功能性消息类均有相对应的特定回复类。从功能位的角度来看,该两种类的主帧功能位之间存在如下关系:

消息回复类功能位 - 消息类功能位 = 0x10

即两类的功能位数值之差以十六进制表示为 0x10。据此设计功能性 Java 消息类后,不需要专门设计对应的回复类,系统会自行使用该通用回复类进行工作。

3 该任务所需消息类编解码器的设计

编码器可将 Java 消息对象编码为数据帧,解码器可讲数据帧解码为指定的 Java 消息对象,上节所述的两种消息类均需要相对应的编解码器,如下所示:

3.1 客户端别名设置编解码器类

该类相比于基础类,新增了编解码器的静态工厂方法,手动传入功能位及功能文字描述,进而生成包含这些参数的编解码器。如此设计,使得所有消息的功能位和文字描述均能够统一管理,降低维护成本。

该类实现了编码、解码方法,故可对消息对象进行编码或对数据帧进行解码。该类的实现如下所示:

/**
 * 「消息对象编解码器」客户端别名设置
 */
public class MsgCodecDeviceName extends BaseMsgCodec {

    private static MsgCodecDeviceName msgCodec = null;

    public MsgCodecDeviceName (int majorMsgId, int subMsgId, String detail) {
        super(majorMsgId, subMsgId, detail);
        msgCodec = this;
    }

    public static MsgDeviceName create(int groupId, int deviceId, String name) {
        return new MsgDeviceName(msgCodec, groupId, deviceId, name);
    }

    @Override
    public ByteBuf code(BaseMsg msg, ByteBuf buffer) {
        MsgDeviceName message = (MsgDeviceName) msg;
        buffer.writeByte(message.getSubMsgId());
        byte[] data = KyToArrayUtil.stringToArray(message.getName());
        buffer.writeShort(data.length);
        buffer.writeBytes(data);
        return buffer;
    }

    @Override
    public MsgDeviceName decode(int groupId, int deviceId, byte[] data) {
        String name = KyToArrayUtil.arrayToString(data);
        return create(groupId, deviceId, name);
    }
}
3.2 通用回复编解码器类

该类相比于基础类,新增了编解码器的静态工厂方法,实现了编解码器,理由与上小节相同。该类的 createByBaseMsg(BaseMsg) 静态方法可通过指定功能消息对象生成相应的回复对象。该类的实现如下所示:

/**
 * 「消息对象编解码器」通用消息回复
 */
public class MsgCodecReplyNormal extends BaseMsgCodec {

    private static MsgCodecReplyNormal msgCodec = null;

    public MsgCodecReplyNormal(int majorMsgId, int subMsgId, String detail) {
        super(majorMsgId, subMsgId, detail);
        msgCodec = this;
    }

    /**
     * 根据收到的消息对象,创建新的通用消息回复对象,
     *
     * @param msg 收到的消息对象
     * @return 新的通用消息回复对象
     */
    public static MsgReplyNormal createByBaseMsg(BaseMsg msg) {
        BaseMsgCodec msgCodec = MsgCodecToolkit.getMsgCodec(msg.getMajorMsgId() + 0x10, msg.getSubMsgId());
        if (msgCodec == null) {
            return null;
        }
        return new MsgReplyNormal(msgCodec, msg.getGroupId(), msg.getDeviceId());
    }

    /**
     * 创建新的通用消息回复对象
     *
     * @param groupId  组号
     * @param deviceId 设备号
     * @return 生成的通用消息回复对象
     */
    private MsgReplyNormal create(int groupId, int deviceId) {
        return new MsgReplyNormal(this, groupId, deviceId);
    }

    @Override
    public ByteBuf code(BaseMsg msg, ByteBuf buffer) {
        MsgReplyNormal message = (MsgReplyNormal) msg;
        buffer.writeByte(message.getSubMsgId());
        buffer.writeShort(0);
        return buffer;
    }

    @Override
    public MsgReplyNormal decode(int groupId, int deviceId, byte[] data) {
        return create(groupId, deviceId);
    }
}

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/71070.html

相关文章

  • 基于 Netty 插拔业务通信协议实现「1」协议描述及基本消息对象设计

    摘要:基本消息对象的设计消息对象的设计主要由两部分组成特定数据帧对应的特定消息对象。该类包含上节数据帧主帧及子帧的所有公共信息,仅仅未包含子帧中的数据体信息,该需求由基本消息对象的子类实现。 开发工程中,有一个常见的需求:服务端程序和多个客户端程序通过 TCP 协议进行通信,通信双方需通信的消息种类众多,并且客户端的数量可能有数万个。为此,双方需要约定尽可能丰富、灵活的数据帧「数据包」协议,...

    Barry_Ng 评论0 收藏0
  • 基于 Netty 插拔业务通信协议实现「3」业务注册及实际工作流程

    摘要:本文仍以该实例为例,探讨该自定义通信协议的具体工作流程,以及如何以注册的形式灵活插拔通信消息对象。进行二进制数据帧的解码操作时,数据帧中已包含了消息的功能位,据此可获取相应的编解码器,而后可以对该数据帧进行解析,生成相应的消息对象。 本文为该系列的第三篇文章,设计需求为:服务端程序和众多客户端程序通过 TCP 协议进行通信,通信双方需通信的消息种类众多。上一篇文章以一个具体的需求为例,...

    LdhAndroid 评论0 收藏0
  • 基于 Webpack4 插拔式微前端架构 - Puzzle

    项目地址 showImg(https://segmentfault.com/img/remote/1460000019380071); 什么是 Puzzle Puzzle 是基于 Vue 和 Webpack4 实现的一种项目结构;业务模块可以像拼图一样与架构模块组合,形成不同的系统,而这一切都是可以在生产环境热插拔的;这意味着你可以随时向你的系统添加新的功能模块,甚至改版整个系统,而不需要全量替换...

    jsliang 评论0 收藏0
  • Hyperledger Fabric(介绍)

    摘要:比特币和以太币属于一类区块链,我们将其归类为公共无许可的区块链技术。例如,在单个企业中部署时,或由受信任的权威机构运作,完全拜占庭容错的共识可能被认为是不必要的,并且对性能和吞吐量造成过度的拖累。 介绍 一般而言,区块链是一个不可变的交易分类账,维护在一个分布式对等节点网络中。这些节点通过应用已经由共识协议验证的交易来维护分类帐的副本,该交易被分组为包括将每个块绑定到前一个块的散列的块...

    yunhao 评论0 收藏0

发表评论

0条评论

Yuqi

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<