CN117640750A - 消息传输方法和装置、消息接收方法和装置、以及通信系统 - Google Patents

Abstract

本公开的实施例提供了一种消息传输方法，适用于网关，所述消息包括数据头和数据体；其中，所述方法包括：确定发送消息的数据格式；确定所述数据体的当前数据格式是否为所述数据格式；在所述数据体的当前数据格式不是所述数据格式的情况下，将所述数据体转换为所述数据格式；确定是否对所述数据体进行压缩；在确定对所述数据体进行压缩的情况下，对所述数据体进行压缩；将所述数据头和所述数据格式的数据体封装在所述消息中；以及发送所述消息。还提供了一种消息接收方法、消息传输装置、消息接收装置以及通信系统。

Description

消息传输方法和装置、消息接收方法和装置、以及通信系统

技术领域

本公开的实施例涉及物联网技术领域，具体来讲，涉及一种消息传输方法和装置、一种消息接收方法和装置以及一种通信系统。

背景技术

物联网(IoT，Internet of things)是新一代信息技术的重要组成部分，又称泛互联。物联网是物物相连的互联网，这里边包含两层含义，一，物联网是物的互联网，是在互联网基础上的延伸和扩展的网络，是互联网的一部分，互联网的基础设施是物联网的信息传递载体；二，其用户端延伸和扩展到了任何物品与物品之间，进行信息交换和通信。因此，物联网可以定义为通过信息传感设备，按照预定的协议，把把任何物品与互联网相连接，进行信息交换和通信，以实现对物品的智能化识别、定位、跟踪、监控和管理的一种网络。

适用于物联网的协议包括消息队列遥测传输协议(Message Queue TelemetryTransport，MQTT)、MQTT-SN(MQTT for Sensor Network)协议、CoAP(ConstrainedApplication Protocol)协议、LwM2M(Lightweight Machine-To-Machine)协议、HTTP协议、LoRaWAN(Long Range WAN)协议、NB-IoT(Narrow Band Internet of Things)协议等。

MQTT是基于客户端服务端架构的发布/订阅范式的消息传输协议，工作在TCP/IP协议族上，是为硬件性能低下的远程设备以及网络状况糟糕的情况下而设计的发布/订阅型消息协议。MQTT v3.1.1版本协议仅仅包含14个协议帧，它格式简单、规范且易于实现，非常适合物联网场景使用。

在MQTT中采用的数据格式是JSON格式。对于JSON格式的数据来讲，其本质上是一个字符串，要求的存储空间较大，特别是在有大量设备的情况下。如果是在带宽较小，或者是在网络环境较差的情况下，消息传输的压力会比较大，而且，错误率会更高。

发明内容

针对上述问题，本公开的至少一个实施例提供了一种的消息传输方法，适用于网关，所述消息包括数据头和数据体；其中，所述方法包括：确定发送消息的数据格式；确定所述数据体的当前数据格式是否为所述数据格式；在所述数据体的当前数据格式不是所述数据格式的情况下，将所述数据体转换为所述数据格式；确定是否对所述数据体进行压缩；在确定对所述数据体进行压缩的情况下，对所述数据体进行压缩；将所述数据头和所述数据格式的数据体封装在所述消息中；以及发送所述消息。

在本公开的一个实施例中，所述数据格式为JSON格式或二进制格式。

在本公开的一个实施例中，以二进制格式表示的数据体包括：数据类型字段、UTC时间字段、设备数字段、设备变长段字段以及点位变长段字段。

在本公开的一个实施例中，所述数据类型字段的长度为1个字节，用于表示数据体中的数据类型；UTC时间字段的长度为4个字节，将时间表示为秒数值；设备数字段的长度为1个字节，表示连接至所述网关的设备的数量；设备变长段字段包括设备ID部分和点位数部分，其中，设备ID部分表示设备参数的数量，长度为4个字节，点位数部分的长度为2个字节，表示下面点位数的总和；以及点位变长段字段包括点位ID部分、点位值长度部分、值部分以及有效性部分，其中，点位ID部分的长度为2个字节，点位值长度部分的长度为1个字节，有效性部分长度为1个字节。

在本公开的一个实施例中，所述数据头包括第一部分，配置为标识发送所述消息的数据格式。

在本公开的一个实施例中，所述数据头包括第二部分，配置为标识发送所述数据体是否被压缩。

在本公开的一个实施例中，在所述数据体被压缩的情况下，采用gzip对所述数据体进行压缩。

在本公开的一个实施例中，所述数据头还包括第三部分，所述第三部分用于指示所采用的网络协议的版本。

本公开的至少一个实施例还提供了一种消息接收方法，适用于RabbitMQ Broker，包括：

从网关接收消息，其中，所述消息包括数据头和数据体；

对所述数据头的第二部分进行解析，确定所述数据体是否被压缩；

在所述数据体未被压缩的情况下，对所述数据头的第一部分进行解析，确定所述数据体的数据格式；

在所述数据体被压缩的情况下，对所述数据体进行解压，然后，根据所述数据头的所述第一部分确定所述数据体的数据格式；以及

根据所述数据格式从所述数据体中读取数据。

在本公开的一个实施例中，所述数据体的数据格式为JSON格式或二进制格式。

在本公开的一个实施例中，以二进制格式表示的数据体包括：数据类型字段、UTC时间字段、设备数字段、设备变长段字段以及点位变长段字段。

在本公开的一个实施例中，所述数据类型字段的长度为1个字节，用于表示数据体中的数据类型；UTC时间字段的长度为4个字节，将时间表示为秒数值；设备数字段的长度为1个字节，表示连接至所述网关的设备的数量；设备变长段字段包括设备ID部分和点位数部分，其中，设备ID部分表示设备参数的数量，长度为4个字节，点位数部分的长度为2个字节，表示下面点位数的总和；以及点位变长段字段包括点位ID部分、点位值长度部分、值部分以及有效性部分，其中，点位ID部分的长度为2个字节，点位值长度部分的长度为1个字节，有效性部分长度为1个字节。

在本公开的一个实施例中，在所述数据体被压缩的情况下，所述数据体是采用gzip压缩的。

在本公开的一个实施例中，所述方法还包括：对所述数据头的第三部分进行解析，确定所采用的网络协议的版本；以及根据所述网络协议的版本读取所述数据体。

本公开的至少一个实施例还提供了一种消息传输装置，适用于网关，所述消息包括数据头和数据体，所述消息传输装置包括：数据格式设置单元，配置为在所述数据头的第一部分中设置所述数据体的数据格式；数据转换单元，配置为在所述数据体的当前数据格式与所述数据格式设置单元设置的数据格式不一致的情况下，将所述数据体转换为所述数据格式设置单元设置的数据格式；消息封装单元，配置为将所述数据头和所述数据体封装在所述消息中；以及消息发送单元，配置为发送封装后的消息。

在本公开的一个实施例中，所述数据格式设置单元设置的数据格式为JSON格式或二进制格式。

在本公开的一个实施例中，以二进制格式表示的数据体包括：数据类型字段、UTC时间字段、设备数字段、设备变长段字段以及点位变长段字段。

在本公开的一个实施例中，所述数据类型字段的长度为1个字节，用于表示数据体中的数据类型；UTC时间字段的长度为4个字节，将时间表示为秒数值；设备数字段的长度为1个字节，表示连接至所述网关的设备的数量；设备变长段字段包括设备ID部分和点位数部分，其中，设备ID部分表示设备参数的数量，长度为4个字节，点位数部分的长度为2个字节，表示下面点位数的总和；以及点位变长段字段包括点位ID部分、点位值长度部分、值部分以及有效性部分，其中，点位ID部分的长度为2个字节，点位值长度部分的长度为1个字节，有效性部分长度为1个字节。

在本公开的一个实施例中，所述消息传输装置还包括：

压缩状态设置单元，配置为设置所述数据体是否处于压缩状态；以及

压缩单元，配置为在所述压缩状态设置单元设置所述数据体处于压缩状态的情况，对所述数据体进行压缩；

其中，所述数据封装单元配置为将所述数据头和压缩后的数据体封装在所述消息中。

在本公开的一个实施例中，所述压缩单元配置为采用gzip对所述数据体进行压缩。

在本公开的一个实施例中，所述消息传输装置还包括：网络协议版本设置单元，配置为在所述数据头的第三部分设置所述网络协议的版本。

本公开的至少一个实施例还提供了一种消息接收装置，其适用于RabbitMQBroker，包括：数据接收单元，配置为从网关接收包括数据头和数据体的消息；数据格式解析单元，配置为对所述数据头的第一部分进行解析，获取所述数据体的数据格式；以及数据体读取单元，配置为根据所述数据格式读取所述数据体。

在本公开的一个实施例中，所述的息接收装置还包括：

压缩状态解析单元，配置为对所述数据头的第二部分进行解析，确定所述数据体是否处于压缩状态；以及

数据解压缩单元，配置为在所述数据体处于压缩状态时，在所述数据体读取单元读取所述数据体之前，对所述数据体解压缩。

在本公开的一个实施例中，所述数据解压缩单元配置为采用gzip对所述数据体进行解压缩。

在本公开的一个实施例中，所述第一部分指示的数据格式为：JSON格式或二进制格式。

在本公开的一个实施例中，二进制格式的数据体包括：数据类型字段、UTC时间字段、设备数字段、设备变长段字段以及点位变长段字段。

在本公开的一个实施例中，所述数据类型字段的长度为1个字节，用于表示数据体中的数据类型；UTC时间字段的长度为4个字节，将时间表示为秒数值；设备数字段的长度为1个字节，表示连接至所述网关的设备的数量；设备变长段字段包括设备ID部分和点位数部分，其中，设备ID部分表示设备参数的数量，长度为4个字节，点位数部分的长度为2个字节，表示下面点位数的总和；以及点位变长段字段包括点位ID部分、点位值长度部分、值部分以及有效性部分，其中，点位ID部分的长度为2个字节，点位值长度部分的长度为1个字节，有效性部分长度为1个字节。

在本公开的一个实施例中，所述消息接收装置还包括：网络协议版本解析单元，配置为对所述数据头的第三部分进行解析，以获得所采用的网络协议的版本；其中所述数据体读取单元还被配置为根据所述网络协议的版本读取所述数据体。

本公开的至少一个实施例还提供了一种通信系统，包括上述任一消息传输装置以及上述任一消息接收装置。

本公开的实施例中，采用二进制格式或JSON格式表示数据体，可以在不同的网络环境下选择传输不同数据格式的数据体，有助于减小发送所述消息时的网络负荷，在数据量较大的情况下，可以对数据体做压缩，以进一步降低数据量。同时，还可以在数据头中标识所采用的网络协议的版本，更进一步地扩展了根据本公开实施例的技术方案的适用性。

附图说明

图1示出了网关和RabbitMQBroker的应用场景示意图；

图2示出了JSON格式数据的一个示例；

图3示出了根据本公开的一个实施例的消息传输方法的流程示意图；

图4示出了数据体以二进制表示的一个示例；

图5示出了根据本公开的一个实施例的消息接收方法的流程图；

图6示出了根据本公开的一个实施例的消息传输装置的示意性框图；

图7示出了根据本公开的另一个实施例的消息传输装置的示意性框图；

图8示出了根据本公开的另一个实施例的消息传输装置的示意性框图；

图9示出了根据本公开的一个实施例的消息接收装置的示意性框图；

图10示出了根据本公开的另一个实施例的消息接收装置的示意性框图；以及

图11示出了根据本公开的另一个实施例的消息接收装置的示意性框图。

具体实施方式

下面通过附图和实施例对本公开进一步详细说明。通过这些说明，本公开的特点和优点将变得更为清楚明确。

在这里专用的词“示例性”意为“用作例子、实施例或说明性”。这里作为“示例性”所说明的任何实施例不必解释为优于或好于其它实施例。尽管在附图中示出了实施例的各种方面，但是除非特别指出，不必按比例绘制附图。

此外，下面所描述的本公开不同实施方式中涉及的技术特征只要彼此之间未构成冲突就可以相互结合。

在物联网中，网关安装在客户现场，连接至现场的各种设备，如图1所示，各种传感设备等设置在现场，通过本地网络连接至网关，而网关通过网络连接至bootstrap server和RabbitMQBroker。RabbitMQBroker又叫RabbitMQ代理，RabbitMQ是一种实现高级消息队列协议的消息中间件，用于分布式系统中存储转发消息，具备可靠性、灵活的路由、集群部署、高可用的队列消息、可视化的管理工具等一系列优点，得到了广泛的应用。RabbitMQBroker主要用于系统间的双向解耦，当生产者产生大量的数据时，消费者无法快速地消费信息，就需要一个类似于中间件的代理服务器，用来处理和保存这些数据，RabbitMQBroker就扮演了这个角色。RabbitMQBroker还连接至时序数据库，为时序数据存提供数据，时序数据库中存储有各种数据应用和报警应用。

在通电后，网关通过HTTP协议向云平台请求bootstrap server返回连接云平台中间件RabbitMQBroker的账号和密码。在获取到RabbitMQBroker的账号和密码之后，网关通过相应端口和云平台提供的证书建立TLS连接。之后网关通过其他一些协议，例如MODBUS/TCP、zigbee等，连接设备并获取数据。网关在与云平台建立的连接的基础上通过网络协议上传数据。云平台上的相关服务会对broker数据进行消费、存储或提供给云平台上其他应用提供数据，例如各种数据应用或报警应用。

在通常的IoT协议中，通常会采用JSON格式进行数据传输。JSON是一种轻量级的数据交换格式，采用完全独立于编程语言的文本格式来存储和表述数据。结构简洁，层次清晰使得JSON成为一种理想的数据交换语言，便于阅读和辨析额，也易于机器解析和生产，有利于网络传输。

在IoT架构中，对于每一个上云的网关，其可以连接多个设备，同时，每个设备下面可以有多个设备参数。假如一个设备下面有8个设备参数，在某一时间点读取该设备下的8个设备参数，所形成的JSON格式的数据如图2所示。

在图2中，datatype表示数据类型，其长度为1字节，0x1为时序数据，0x10为事件数据,0x11为点位报警，0x100是点位解除报警,0x101为设备离线报警,0x110为设备离线解除报警，图中的数值为1，表示这是一条时序数据，time表示UTC时间，表示为1970年之后的秒数值，长度为4字节，可以支持到2106年，“"hardwareId":758313,”表示ID编号为758313的设备，“"hardwareId":1,”、“"hardwareId":2,”、“"hardwareId":3,”、“"hardwareId":4,”、“"hardwareId":5,”、“"hardwareId":6,”、“"hardwareId":7,”以及“"hardwareId":8,”表示设备参数的ID。例如，“"hardwareId":758313,”表示编号为758313的电脑，而“"hardwareId":1,”、“"hardwareId":2,”、“"hardwareId":3,”、“"hardwareId":4,”、“"hardwareId":5,”、“"hardwareId":6,”、“"hardwareId":7,”以及“"hardwareId":8,”分别表示该电脑中的多个设备参数，例如，电压、电流、温度、风速等等。

对于数据

其表示在该时间点，参数ID表示该时间点参数Id为1的参数的值为16，有效。其他的数据段的含义与该数据段的含义类似。

对于图2中所示的数据，其对应的JSON文件的大小大概是879B。

在网关连接更多的设备且每个设备有更多的设备参数的情况下，在每次查询时，所产生的数据对应的JSON文件会更大。这对于带宽较小，或者是在网络较差的环境下，数据传输的压力会比较大，而且，错误率会更高。

针对此，本公开的至少一个实施例提供了一种消息传输方法，适用于网关，所述消息包括数据头和数据体；

其中，所述方法包括：

确定发送消息的数据格式；

确定所述数据体的当前数据格式是否为所述数据格式；

在所述数据体的当前数据格式不是所述数据格式的情况下，将所述数据体转换为所述数据格式；

确定是否对所述数据体进行压缩；

在确定对所述数据体进行压缩的情况下，对以所述数据格式表示的所述数据体进行压缩，将所述数据头和已经压缩的所述数据体封装在所述消息中；

在不需要对所述数据体进行压缩的情况下，将所述数据头和以所述数据格式表示的所述数据体封装在所述消息中；以及

发送所述消息。

图3示出了根据公开的一个实施例的消息传输方法的流程图。如图3所示，在本公开的一个实施例中，消息传输方法包括：S1，确定发送消息的数据格式；S2，确定所述数据体的当前数据格式是否为所述数据格式；S3，在所述数据体的当前数据格式不是所述数据格式的情况下，将所述数据体转换为所述数据格式；S4，确定是否对所述数据体进行压缩；S5，在确定对所述数据体进行压缩的情况下，对所述数据体进行压缩；S6，将所述数据头和所述数据格式的数据体封装在所述消息中；以及S7，发送所述消息。

在本公开的一个实施例中，所述数据格式为JSON格式或二进制格式。在本公开的另一个实施例中，所述消息传输方法是基于MQTT协议的。当然，根据本公开实施例的消息传输方法也可以基于其他的网络协议，例如，MQTT-SN(MQTT for Sensor Network)协议、CoAP(Constrained Application Protocol)协议、LwM2M(Lightweight Machine-To-Machine)协议、HTTP协议、LoRaWAN(Long Range WAN)协议、NB-IoT(Narrow Band Internet ofThings)协议等。

在上文中已经参照图2对JSON格式进行了描述。当网关从与其连接的各个设备获取数据以上传至RabbitMQ Broker时，根据设备的数量以及每个设备的设备参数的数量，确定要上传的数据量。如果设备的数量较少且每个设备的设备参数也较少，此时要上传的数据在JSON格式下也不大。在这种情况下，可以不用转换数据格式，直接以JSON格式进行传输。

如果与网关连接的设备的数量很大，或者与网关连接的设备的数量不大，但每个设备的设备参数很多，此时要上传的数据在JSON格式下比较大。如果以JSON格式发送消息，窄带模式下或者在网络信号差的情况下进行发送，耗时较长，且容易出现传输错误。在这种情况下，需要采用更简洁，数据量更小的数据格式进行发送。

针对这种情况，在本公开的一个实施例中采用二进制格式表示数据体。所采用的二进制格式对应的结构体如表1所示。

表1

从表1中可以看到，所述二进制格式包括：数据类型字段、UTC时间字段、设备数字段、设备变长段字段、点位变长段字段。数据类型字段表示封装在消息中的数据体中的数据的类型，长度为1个字节，0x1为时序数据，0x10为事件数据,0x11为点位报警，0x100是点位解除报警,0x101为设备离线报警,0x110为设备离线解除报警。UTC时间字段的长度为4字节，表示1970年之后的秒数值，其长度可以支持到2106年。设备数字段的长度为一个字节，表示网关下面连接的设备数的总和，一个数据包最多支持256个设备。如果是报警或接触报警，一般设备数量为1。设备变长段字段包括设备ID部分和点位数部分。设备ID部分表示设备参数的数量，长度为4个字节，可支持4,294,967,296个设备参数。点位数部分的长度为2个字节，表示下面点位数的总和，一个数据包最多支持65536个点位，当数据类型为设备离线报警和离线解除报警时，点位数为0，后面的点位变长段不存在。点位变长段字段包括点位ID部分、点位值长度部分、值部分以及有效性部分。点位ID部分的长度为2个字节，可以支持65536个点位。点位值长度部分的长度为1个字节，值1代表后面的值为1个字节，值2代表后面的值为2个字节，以此类推，String类型不固定长度，但是，不能超过255。值部分的长度是点位值长度部分描述的字节数。如果是报警信号，则是发生报警时的值。如果是接触报警信号，则是接触报警时的值。有效性的长度为一个字节，0表示无效，1表示有效。

下列数据是按照二进制格式进行编码的一个数据体的例子。

【69 1 98 41 123-13 2 0 11-110 41 0 8 0 1 2 0 16 0 0 2 2 0 16 0 0 3 40 0 0 32 0 0 4 4 66 0-93-41 0 0 5 4 0 0 0 32 0 0 6 8 0 0 0 0 0 0 0 64 0 0 7 864 80 40-11-62-113 92 41 0 0 8 8 64 80 40-11-62-113 92 41 0 0 11-110 42 0 8 01 2 0 16 0 0 2 2 0 16 0 0 3 4 0 0 0 32 0 0 4 4 66 0-93-41 0 0 5 4 0 0 0 32 00 6 8 0 0 0 0 0 0 0 64 0 0 7 8 64 80 40-11-62-113 92 41 0 0 8 8 64 80 40-11-62-113 92 41 0】

对上述二进制格式数据进行解析，可以得到图4所示的结果。

在本公开的实施例中，消息由数据头(payload)和数据体构成，其中，数据头的长度为一个字节(1byte)，定义了数据体的格式，数据头的结构如表2所示。

表2

PAYLOAD

如表2所示，数据头的低4位定义了数据体的格式，其中Bit 0定义了数据体的数据格式，Bit 1定义了数据体是否被压缩，Bit 3-Bit 2定义了业务数据能力标识。

当Bit 0为0时，表示数据体中的数据采用JSON格式，当Bit 0为1时表示数据体中的数据采用二进制格式。

当Bit 1为0时，表示数据体中的数据未压缩，当Bit 1为1时，表示数据体中的数据被压缩。

Bit 3-Bit 2定义了业务数据能力标识，其可以用来定义所采用的网络协议的版本，用不同的赋值来标识不同的网络协议的版本。

要发送数据体时，首先确定发送所述数据体的数据格式。这会根据连接至网关的设备数量以及每个设备的设备参数数量确定。当连接至网关的设备数量较小或者每个设备的设备参数较小，从每个设备发送至网关的数据体以JSON格式表示时数据量较小，此时可以以JSON格式传输所述数据体。此时，无需对数据体进行格式转换。为了进一步减小数据传输量，可以对数据体进行压缩。当然，在数据量较小的情况下，可以不进行压缩。压缩之后，将所述数据头和所述数据体封装在所述消息中，所述数据头的第一部分标识所述数据体的数据格式，所述数据头的第二部分标识所述数据体是否被压缩。之后，将所述消息从网关传输至RabbitMQ Broker。RabbitMQ Broker从所述消息中解析出所述数据体行存储在时序数据库中，以供数据应用和报警应用使用。

在本公开的某些实施例中，与网关连接的设备的数量特别大，或者与网关连接的设备的数量是特别大，但每个设备的设备参数特别多，在这些情况下，即使以二进制格式表示数据体，二进制格式的数据体依然很大。在窄带模式下或者在网络信号差的情况下传输消息，依然耗时较长，且容易出现传输错误。

在确定对所述数据体进行压缩的情况下，在所述数据体的当前数据格式与所述数据格式一致的情况下，对所述数据体直接进行压缩。在所述数据体的当前数据格式与所述数据格式不一致的情况下，将所述数据体转换为所述数据格式，并对所述数据格式的所述数据体进行压缩。

需要理解的是，被压缩的数据体可以是JSON格式，也可以是二进制格式，或者，被压缩的数据体也可以是其他的数据格式，本公开的实施例对此不作限定。

为了进一步减小消息的大小，在本公开的一个实施例中，采用gzip对数据体进行压缩。Gzip是基于HTTP协议的编码技术，是一种非常普遍的一种数据压缩格式，或者说一种文件格式。使用gzip对数据进行压缩，可以减少数据传输量，减少对网络带宽的消耗。继续以图2所示的JSON格式的数据为例进行说明。图2中所示的JSON格式的数据体的大小为879b，转换为以二进制格式表示的数据体之后大小为189b，而以JSON格式表示的数据体在被gzip格式压缩之后的数据体大小为206b。

而当与网关连接的设备数量为10时，以二进制格式表示的数据体的大小为896b，在采用gzip格式压缩之后，压缩二进制格式数据体的大小为558b。显然，通过压缩可以进一步减小数据体的大小，在封装之后发送消息时，可以进一步降低网络的负荷，降低传输时间，减小传输错误率。

在本公开的一个实施例中，不同网关部署时间的差异，在不同的网关部署时采用的网络协议的版本可能不同，不同的网络协议版本在消息格式上会存在差异。针对此，在本公开的一个实施例中，数据头还包括第三部分，所述第三部分用于指示所采用的网络协议的版本。这样，在连接至RabbitMQ Broker的网关采用不用的网络协议版本，RabbitMQBroker接收到不同网关发送的消息时，RabbitMQ Broker可以按照数据头中的第三部分所指示的网络协议的版本，对收到的消息进行解析，可以正确地解析出所接收的消息中包含的数据，消除了在RabbitMQ Broker连接有不同版本的网关的情况下误读数据的可能性。

在根据本公开实施例的消息传输方法中，采用多种数据格式，基于连接至网关的设备数量以及每个设备的设备参数的数量，在特定的网络环境下降低数据体的数据量，减小传输消息时的网络符合，有效降低消息传输的错误率。

针对本公开所提供的上述消息传输方法，本公开的至少一个实施例还提供了一种消息读取方法，适用于RabbitMQ Broker，如图5所示，所述方法包括：

S11，从网关接收消息，其中，所述消息包括数据头和数据体；

S12，对所述数据头的第二部分进行解析，确定所述数据体是否被压缩；

S13，在所述数据体未被压缩的情况下，所述方法进行至S14，在所述数据体被压缩的情况下，对所述数据体进行解压，然后，所述方法进行至S14；

S14，对所述数据头的第一部分进行解析，确定所述数据体的数据格式；以及

S15，根据所述数据格式从所述数据体中读取数据。

如上文实施例所述，从网关发送至RabbitMQ Broker的消息包括数据头和数据体，数据头中的第一部分用于指示所述数据体的数据格式，数据头的第二部分用于指示所述数据体是否被压缩，这表示消息中所包含的数据体以多种数据格式中的一种表示，并可能已经被压缩。通过对数据头的第一部分进行解析，可以确定所述数据体的数据格式，通过对数据头的第二部分进行解析，可以确定所述数据体是否被压缩。在数据体被压缩了的情况下，如果没有对数据体先进行解压，即使知道数据体处于何种数据格式下，也无法从消息中读出所述数据体。因此，在该方法中，先确定所述数据体是否被压缩，在所述数据体被压缩的情况下，先对所述数据体进行解压，然后确定所述数据体的数据格式，再从所述数据体中读出数据。

在本公开的一个实施例中，所述数据体的数据格式为JSON格式或二进制格式。如上文的消息传输实施例中所述，采用二进制格式可以有效减小数据体的数据量，减小发送所述消息时的网络负荷，在数据量较大的情况下，可以对数据体做压缩，以进一步降低数据量。在本公开的一个实施例中，所述数据体是采用gzip压缩的。

由于连接至网关的设备可能是在不同的时间段部署的，在这些设备部署时会采用不用的网络协议版本。针对此，所述数据头还包括第三部分，所述第三部分用于标识所采用的网络协议的版本。此时，根据本公开实施例的消息读取方法还包括：对所述数据头的第三部分进行解析，确定所采用的网络协议的版本；以及根据所述网络协议的版本读取所述数据体。

通过使包含在消息中的数据体具有不同的数据格式，可以有效地降低包含在消息中的数据体的大小，通过对所述数据体进行压缩，可以进一步减小消息的大小。同时，在数据头中包含所采用的网络协议的版本，可以扩展该方法的适用性。

本公开的至少一个实施例还提供了一种消息传输装置，适用于网关，所述消息包括数据头和数据体。如图6所示，所述消息传输装置600包括：

数据格式设置单元601，配置为在所述数据头的第一部分中设置所述数据体的数据格式；

数据转换单元602，配置为在所述数据体的当前数据格式与所述数据格式设置单元设置的数据格式不一致的情况下，将所述数据体转换为所述数据格式设置单元设置的数据格式；

消息封装单元603，配置为将所述数据头和所述数据体封装在所述消息中；以及

消息发送单元604，配置为发送封装后的消息。

在本公开的一个实施例中，所述数据格式为JSON格式或二进制格式。

通过使消息中的数据体具有不同的数据格式，可以在数据量较大的情况下采用占用空间更小的数据格式，可以有效减小数据体的数据量，减小发送所述消息时的网络负荷。

为了在连接至网关的设备数量较大或者每个设备的设备参数较多的情况下减小传输消息的网络负荷并降低错误率，如图7所示，在本公开的一个实施例中，所述消息传输装置600还包括：

压缩状态设置单元605，配置为设置所述数据体是否处于压缩状态；以及

压缩单元606，配置为在所述压缩状态设置单元605设置所述数据体处于压缩状态的情况，对所述数据体进行压缩；

其中，所述数据封装单元603配置为将所述数据头和压缩后的数据体封装在所述消息中。

例如，所述压缩单元606配置为采用gzip对所述数据体进行压缩。

为了扩展所述消息传输装置600的适用性，在本公开的一个实施例中，如图8所示，所述消息传输装置600还包括网络协议版本设置单元607，配置为在所述数据头的第三部分设置所所采用的网络协议的版本。通过在消息中封装所采用的网络协议的版本，可以增大该消息传输装置的扩展性，并提高适用性。

根据本公开实施例的消息传输装置的实施方式与上文所述的消息传输方法类似，其内容可以参考上文的消息传输方法，在此不再赘述。

本公开的至少一个实施例还提供了一种消息接收装置，适用于RabbitMQ Broker。

如图9所示，根据本公开的一个实施例的消息接收装置900包括：

数据接收单元901，配置为从网关接收包括数据头和数据体的消息；

数据格式解析单元902，配置为对所述数据头的第一部分进行解析，确定所述数据体的数据格式；以及

数据体读取单元903，配置为根据所述数据格式读取所述数据体。

在接收到的消息中的数据体可以以不同的数据格式表示，通过数据格式读取单元902确定所述数据体的数据可以，可以保证消息接收装置以正确的数据格式从消息中读出数据体。这样，在传输消息时，可以采用使数据体更小的数据格式，减小消息传输时网络的负荷。在本公开的一个实施例中，所述数据体的数据格式为JSON格式或二进制格式。

在本公开的一些实施例中，所接收到的消息中的数据体是压缩格式的，为了能够正确地从消息中读取数据体，如图10所示，所述消息接收装置还包括：压缩状态读取单元904，配置为对所述数据头的第二部分进行解析，确定所述数据体是否处于压缩状态；以及

数据解压缩单元905，配置为在所述第二部分指示所述数据体处于压缩状态时，在所述数据体读取单元读取所述数据体之前，对所述数据体解压缩。

通过使消息接收装置可以接收压缩的数据体，可以进一步减小传输消息时网络的负荷，降低误码率。

例如，所接收到的消息中的数据体是以gzip格式压缩的，相应地，在本公开的一个实施例中，所述数据解压缩单元905配置为采用gzip对所述数据体进行解压缩。

如果连接至网关的设备采用了不同版本的网络协议，在RabbitMQ Broker不清楚网络协议版本的情况下，可能导致无法读出消息中的数据体的情形。这对这种情况，在传输消息时会在数据头中标识所采用的网络协议的版本，在接收到消息时，确定所采用的网络协议的版本，可以正确地读取消息中的数据体。

在本公开的一个实施例中，如图11所示，所述消息接收装置还包括网络协议版本解析单元906，配置为对所述数据头的第三部分进行解析，确定所采用的网络协议的版本；其中，所述数据体读取单元903根据所述网络协议的版本读取所述数据体。

通过设置网络协议版本解析单元，可以更进一步地扩展根据本公开实施例的消息接收装置的适应性。

根据本公开实施例的消息接收装置的实施方式与根据本公开实施例的消息接收方法类似，有关实施的具体内容，可以参照上文对根据本公开实施例的消息接收方法的描述，在此不再赘述。

本公开的至少一个实施例还提供了一种通信系统，包括根据上述任何实施例的消息传输装置和根据上述任一实施例的消息接收装置。

在该通信系统中，数据体可以以不同的数据格式发送和接收，并在数据量较大的情况下对数据体进行压缩，同时，还针对基于不同网络协议版本的网关提供了版本读取功能，进一步扩展了该通信系统的适用性。

在本公开的描述中，需要说明的是，术语“上”、“下”、“内”、“外”、“前”、“后”、“左”、“右”等指示的方位或位置关系为基于本公开工作状态下的方位或位置关系，仅是为了便于描述本公开和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本公开的限制。

在本公开的描述中，需要说明的是，除非另有明确的规定和限定，术语“安装”“相连”“连接”应作广义理解。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本公开中的具体含义。

以上结合了优选的实施方式对本公开进行了说明，不过这些实施方式仅是范例性的，仅起到说明性的作用。在此基础上，可以对本公开进行多种替换和改进，这些均落入本公开的保护范围内。

Claims (29)

1.一种消息传输方法，适用于网关，所述消息包括数据头和数据体；其中，所述方法包括：

确定发送消息的数据格式；

确定所述数据体的当前数据格式是否为所述数据格式；

在所述数据体的当前数据格式不是所述数据格式的情况下，将所述数据体转换为所述数据格式；

确定是否对所述数据体进行压缩；

在确定对所述数据体进行压缩的情况下，对所述数据体进行压缩；

将所述数据头和所述数据格式的数据体封装在所述消息中；以及

发送所述消息。

2.根据权利要求1所述的消息传输方法，其中，所述数据格式为JSON格式或二进制格式。

3.根据权利要求2所述的消息传输方法，其中，以二进制格式表示的数据体包括：数据类型字段、UTC时间字段、设备数字段、设备变长段字段以及点位变长段字段。

4.根据权利要求3所述的消息传输方法，其中：

所述数据类型字段的长度为1个字节，用于表示数据体中的数据类型；

UTC时间字段的长度为4个字节，将时间表示为秒数值；

设备数字段的长度为1个字节，表示连接至所述网关的设备的数量；

设备变长段字段包括设备ID部分和点位数部分，其中，设备ID部分表示设备参数的数量，长度为4个字节，点位数部分的长度为2个字节，表示下面点位数的总和；以及

点位变长段字段包括点位ID部分、点位值长度部分、值部分以及有效性部分，其中，点位ID部分的长度为2个字节，点位值长度部分的长度为1个字节，有效性部分长度为1个字节。

5.根据权利要求1至4中任何一项所述的消息传输方法，其中，所述数据头包括第一部分，配置为标识发送所述消息的数据格式。

6.根据权利要求1至4中任何一项所述的消息传输方法，其中，所述数据头包括第二部分，配置为标识发送所述数据体是否被压缩。

7.根据权利要求6所述的消息传输方法，其中，在所述数据体被压缩的情况下，采用gzip对所述数据体进行压缩。

8.根据权利要求1至4中任何一项所述的消息传输方法，其中，所述数据头还包括第三部分，所述第三部分用于指示所采用的网络协议的版本。

9.一种消息接收方法，适用于RabbitMQ Broker，包括：

从网关接收消息，其中，所述消息包括数据头和数据体；

对所述数据头的第二部分进行解析，确定所述数据体是否被压缩；

在所述数据体未被压缩的情况下，对所述数据头的第一部分进行解析，确定所述数据体的数据格式；

在所述数据体被压缩的情况下，对所述数据体进行解压，然后，根据所述数据头的所述第一部分确定所述数据体的数据格式；以及

根据所述数据格式从所述数据体中读取数据。

10.根据权利要求9所述的消息接收方法，其中，所述数据体的数据格式为JSON格式或二进制格式。

11.根据权利要求10所述的消息接收方法，其中，以二进制格式表示的数据体包括：数据类型字段、UTC时间字段、设备数字段、设备变长段字段以及点位变长段字段。

12.根据权利要求11所述的消息接收方法，其中：

所述数据类型字段的长度为1个字节，用于表示数据体中的数据类型；

UTC时间字段的长度为4个字节，将时间表示为秒数值；

设备数字段的长度为1个字节，表示连接至所述网关的设备的数量；

设备变长段字段包括设备ID部分和点位数部分，其中，设备ID部分表示设备参数的数量，长度为4个字节，点位数部分的长度为2个字节，表示下面点位数的总和；以及

点位变长段字段包括点位ID部分、点位值长度部分、值部分以及有效性部分，其中，点位ID部分的长度为2个字节，点位值长度部分的长度为1个字节，有效性部分长度为1个字节。

13.根据权利要求9至12中任何一项所述的消息接收方法，其中，在所述数据体被压缩的情况下，所述数据体是采用gzip压缩的。

14.根据权利要求9至12中任何一项所述的消息接收方法，其中，所述方法还包括：

对所述数据头的第三部分进行解析，确定所采用的网络协议版本；以及

根据所述网络协议的版本读取所述数据体。

15.一种消息传输装置，适用于网关，配置为传输消息，所述消息包括数据头和数据体，所述消息传输装置包括：

数据格式设置单元，配置为在所述数据头的第一部分中设置所述数据体的数据格式；

数据转换单元，配置为在所述数据体的当前数据格式与所述数据格式设置单元设置的数据格式不一致的情况下，将所述数据体转换为所述数据格式设置单元设置的数据格式；

消息封装单元，配置为将所述数据头和所述数据体封装在所述消息中；以及

消息发送单元，配置为发送封装后的消息。

16.根据权利要求15所述的消息传输装置，其中，所述数据格式设置单元设置的数据格式为JSON格式或二进制格式。

17.根据权利要求16所述的消息传输装置，其中，以二进制格式表示的数据体包括：数据类型字段、UTC时间字段、设备数字段、设备变长段字段以及点位变长段字段。

18.根据权利要求17所述的消息传输装置，其中，

所述数据类型字段的长度为1个字节，用于表示数据体中的数据类型；

UTC时间字段的长度为4个字节，将时间表示为秒数值；

设备数字段的长度为1个字节，表示连接至所述网关的设备的数量；

设备变长段字段包括设备ID部分和点位数部分，其中，设备ID部分表示设备参数的数量，长度为4个字节，点位数部分的长度为2个字节，表示下面点位数的总和；以及

点位变长段字段包括点位ID部分、点位值长度部分、值部分以及有效性部分，其中，点位ID部分的长度为2个字节，点位值长度部分的长度为1个字节，有效性部分长度为1个字节。

19.根据权利要求15至18中任何一项所述的消息传输装置，其还包括：

压缩状态设置单元，配置为设置所述数据体是否处于压缩状态；以及

压缩单元，配置为在所述压缩状态设置单元设置所述数据体处于压缩状态的情况，对所述数据体进行压缩；

其中，所述数据封装单元配置为将所述数据头和压缩后的数据体封装在所述消息中。

20.根据权利要求19所述的消息传输装置，其中，所述压缩单元配置为采用gzip对所述数据体进行压缩。

21.根据权利要求15至18中任何一项所述的消息传输装置，其还包括：网络协议版本设置单元，配置为在所述数据头的第三部分设置传输消息所采用的网络协议的版本。

22.一种消息接收装置，其适用于RabbitMQ Broker，包括：

数据接收单元，配置为从网关接收包括数据头和数据体的消息；

数据格式解析单元，配置为对所述数据头的第一部分进行解析，获取所述数据体的数据格式；以及

数据体读取单元，配置为根据所述数据格式读取所述数据体。

23.根据权利要求22所述的消息接收装置，其还包括：

压缩状态解析单元，配置为对所述数据头的第二部分进行解析，确定所述数据体是否处于压缩状态；以及

数据解压缩单元，配置为在所述数据体处于压缩状态时，在所述数据体读取单元读取所述数据体之前，对所述数据体解压缩。

24.根据权利要求23所述的消息接收装置，其中，所述数据解压缩单元配置为采用gzip对所述数据体进行解压缩。

25.根据权利要求22至24中任何一项所述的消息接收装置，其中，所述第一部分指示的数据格式为JSON格式或二进制格式。

26.根据权利要求25所述的消息接收装置，其中，二进制格式的数据体包括：数据类型字段、UTC时间字段、设备数字段、设备变长段字段以及点位变长段字段。

27.根据权利要求26所述的消息接收装置，其中，

所述数据类型字段的长度为1个字节，用于表示数据体中的数据类型；

UTC时间字段的长度为4个字节，将时间表示为秒数值；

设备数字段的长度为1个字节，表示连接至所述网关的设备的数量；

设备变长段字段包括设备ID部分和点位数部分，其中，设备ID部分表示设备参数的数量，长度为4个字节，点位数部分的长度为2个字节，表示下面点位数的总和；以及

点位变长段字段包括点位ID部分、点位值长度部分、值部分以及有效性部分，其中，点位ID部分的长度为2个字节，点位值长度部分的长度为1个字节，有效性部分长度为1个字节。

28.根据权利要求22至24中任何一项所述的消息接收装置，其还包括：

网络协议版本解析单元，配置为对所述数据头的第三部分进行解析，以获得所采用的网络协议的版本；其中所述数据体读取单元还被配置为根据所述网络协议的版本读取所述数据体。

29.一种通信系统，其包括根据权利要求15中所述的消息传输装置以及权利要求22所述的消息接收装置。