通信方法和通信装置

摘要

本申请提供了一种通信方法和通信装置，该通信方法包括：对多个客户端分组，得到至少两个设备组，所述至少两个设备组的每个设备组中包括至少两个客户端；接收第一客户端发送的发布请求，所述发布请求包括第一数据，所述第一数据对应第一主题，所述发布请求用于请求所述MQTT服务器发布所述第一数据；确定所述第一客户端所属的第一设备组，并向所述第一设备组内的第二客户端发送发布消息，所述发布消息包括所述第一数据。本申请实施例的通信方法所述MQTT服务器对客户端分组，在各个设备组中进行消息发布/订阅，能够增强消息发布/订阅的效率和安全性。

权利要求

1.一种通信方法，其特征在于，应用于消息队列遥测传输MQTT服务器，所述方法包括：对多个客户端分组，得到至少两个设备组，所述至少两个设备组的每个设备组中包括至少两个客户端；

接收第一客户端发送的发布请求，所述发布请求包括第一数据，所述第一数据对应第一主题，所述发布请求用于请求所述MQTT服务器发布所述第一数据；

确定所述第一客户端所属的第一设备组，其中，所述第一设备组为所述至少两个设备组中的任一设备组，并向所述第一设备组内的第二客户端发送发布消息，所述发布消息包括所述第一数据。

2.根据权利要求1所述的方法，其特征在于，所述接收第一客户端发送的发布请求之前，所述方法还包括：接收所述第二客户端发送的订阅请求，所述订阅请求携带有所述第一主题的指示信息，所述订阅请求用于请求所述MQTT服务器向所述第二客户端发送所述第一主题对应的数据。

3.根据权利要求1或2所述的方法，其特征在于，所述对多个客户端分组包括：确定分组条件，所述分组条件包括被划分至同一设备组的客户端的身份标识所需要满足的条件，其中，一个身份标识能够唯一地指示一个客户端；

根据所述多个客户端的身份标识和所述分组条件，对所述多个客户端分组。

4.根据权利要求3所述的方法，其特征在于，在根据所述多个客户端的身份标识和所述分组条件，对所述多个客户端分组之前，所述方法还包括：接收所述多个客户端中每个客户端发送的所述客户端的标识信息，所述客户端的标识信息用于指示所述客户端的身份标识。

5.根据权利要求3所述的方法，其特征在于，所述确定所述第一客户端所属的第一设备组包括：根据所述第一客户端的身份标识和所述分组条件，确定所述第一设备组。

6.根据权利要求1或2所述的方法，其特征在于，在所述对多个客户端分组之前，所述方法还包括：确定所述多个客户端中的每个客户端允许被划分至设备组。

7.根据权利要求6所述的方法，其特征在于，所述确定所述多个客户端中的每个客户端允许被划分至设备组，包括：接收所述多个客户端中每个客户端发送的分组标记，每个分组标记用于指示所对应的客户端是否允许被划分至设备组。

8.根据权利要求7所述的方法，其特征在于，所述分组标记承载于连接请求消息，其中，所述连接请求消息用于请求与所述MQTT服务器建立连接。

9.一种通信装置，其特征在于，应用于消息队列遥测传输MQTT服务器，所述装置包括：分组单元，用于对多个客户端分组，得到至少两个设备组，所述至少两个设备组的每个设备组中包括至少两个客户端；

接收单元，用于接收第一客户端发送的发布请求，所述发布请求包括第一数据，所述第一数据对应第一主题，所述发布请求用于请求所述MQTT服务器发布所述第一数据；

确定单元，用于确定所述第一客户端所属的第一设备组，其中，所述第一设备组为所述至少两个设备组中的任一设备组；

发送单元，用于向所述第一设备组内的第二客户端发送发布消息，所述发布消息包括所述第一数据。

10.根据权利要求9所述的装置，其特征在于，所述接收单元还用于接收所述第二客户端发送的订阅请求，所述订阅请求携带有所述第一主题的指示信息，所述订阅请求用于请求所述MQTT服务器向所述第二客户端发送所述第一主题对应的数据。

11.根据权利要求9或10所述的装置，其特征在于，所述分组单元具体用于：确定分组条件，所述分组条件包括被划分至同一设备组的客户端的身份标识所需要满足的条件，其中，一个身份标识能够唯一地指示一个客户端；

根据所述多个客户端的身份标识和所述分组条件，对所述多个客户端分组。

12.根据权利要求11所述的装置，其特征在于，所述接收单元还用于在根据所述多个客户端的身份标识和所述分组条件，对所述多个客户端分组之前，接收所述多个客户端中每个客户端发送的所述客户端的标识信息，所述客户端的标识信息用于指示所述客户端的身份标识。

13.根据权利要求11所述的装置，其特征在于，所述确定单元具体用于根据所述第一客户端的身份标识和所述分组条件，确定所述第一设备组。

14.根据权利要求9或10所述的装置，其特征在于，所述确定单元还用于在所述MQTT服务器对多个客户端分组之前，确定所述多个客户端中的每个客户端允许被划分至设备组。

15.根据权利要求14所述的装置，其特征在于，所述确定单元确定所述多个客户端中的每个客户端允许被划分至设备组具体包括：所述接收单元接收所述多个客户端中每个客户端发送的分组标记，每个分组标记用于指示所对应的客户端是否允许被划分至设备组。

16.根据权利要求15所述的装置，其特征在于，所述分组标记承载于连接请求消息，其中，所述连接请求消息用于请求与所述MQTT服务器建立连接。

17.一种系统，其特征在于，包括权利要求9-16中任意一项所述的通信装置。

说明书

通信方法和通信装置

技术领域

[0001] 本申请涉及通信领域，更具体地，涉及通信领域中的一种通信方法和通信装置。

背景技术

[0002] 随着智能硬件和移动互联网技术的快速发展，物联网技术发展迅速，但由于其受限的环境特性，传统的互联网协议越来越难以满足物联网的需要，这主要体现在移动网络代价昂贵、带宽低、可靠性差，而且处理器和内存资源都十分有限，与此同时物联网下海量在线设备产生庞大数据，给云端带来很大的网络开销和处理压力。在这种背景下，消息队列遥测传输(Message Queue Telemetry Transport，MQTT)协议应运而生。

[0003] MQTT协议最早是由国际商业机器公司(International Business Machines Corporation，IBM)开发的一个即时通讯协议，MQTT协议是一个客户端/服务器架构的发布/订阅模式的消息传输协议，其设计遵循轻巧、开放、简单、规范、易于实现的原则。其实现基于传输控制协议/因特网互联协议(Transmission Control  Protocol/Internet Protocol，TCP/IP)或其他有序、可靠、双向的网络连接，并且提供了简单、轻量级的发布/订阅特性，这些特性使得它对很多场景来说都是很好的选择，特别是对于受限的环境如机器与机器的通信(machine-to-machine，M2M)以及物联网环境(Internet of Things，IoT)，因而被广泛应用在物联网、移动互联网中，例如汽车、智慧城市、工业4.0、智能家居、医疗医护等等。

[0004] MQTT协议是为大量计算能力有限，且工作在低带宽不可靠的网络的远程传感器和控制设备通讯而设计的协议，具有以下的几项基本特性：

[0005] 使用发布/订阅消息模式，提供一对多的消息发布机制，解除应用程序耦合；

[0006] 对负载内容屏蔽的消息传输；

[0007] 基于TCP/IP或其他有序、可靠、双向的网络连接实现；

[0008] 具有三种消息发布服务质量(Quality of service，QoS)：

[0009] “至多一次”：消息发布完全依赖底层的TCP/IP网络，尽操作环境所能提供的最大努力分发消息，可能会发送消息丢失或重复，例如，这个等级可用于环境传感器数据，单次的数据丢失没关系，因为不久之后会再次发送；

[0010] “至少一次”：确保消息到达，但是消息重复可能会发生；

[0011] “只有一次”：确保消息到达且保证消息只到达一次，例如，这个等级可用在一个计费系统中，这里如果消息重复或丢失会导致计费系统不正确的收费；

[0012] 小型传输，开销很小，协议交换最小化，以降低网络流量；

[0013] 使用遗愿(Last Will)和遗嘱(Testament)特性通知有关各方客户端异常终端的机制。

[0014] 现有的基于MQTT协议的发布/订阅模式，客户端数量很多时消息转发的性能会降低。在物联网技术迅速发展的过程中，客户端的数量会越来越庞大，因此，如何提高消息发布/订阅效率和安全保障成为亟需解决的问题。

发明内容

[0015] 本申请提供了一种通信方法和通信装置，能够提高MQTT服务器处理消息发布/订阅的效率和安全性。

[0016] 第一方面，提供了一种通信方法，应用于消息队列遥测传输MQTT服务器，该方法包括：对多个客户端分组，得到至少两个设备组，所述至少两个设备组的每个设备组中包括至少两个客户端；

[0017] 接收第一客户端发送的发布请求，所述发布请求包括第一数据，所述第一数据对应第一主题，所述发布请求用于请求所述MQTT服务器发布所述第一数据；

[0018] 确定所述第一客户端所属的第一设备组，并向所述第一设备组内的第二客户端发送发布消息，所述发布消息包括所述第一数据。

[0019] 根据本申请实施例的通信方法，通过使MQTT服务器对客户端分组，将客户端分成不同的设备组，MQTT服务器在接收到第一客户端发送的第一数据之后，确定第一客户端所属的第一设备组，并将发布消息转发给第一设备组中的第二客户端，发布消息包括所述第一数据，其中，第二客户端可以是一个或者多个设备，且发布消息还可以包括第一设备组的标识，本申请实施例的通信方法能够确定第一客户端发送的数据转发给所属同一设备组的第二客户端，确保了消息转发的安全性，并且对于MQTT服务器来说在一个设备组内进行消息转发可以提高消息转发的效率。

[0020] 结合第一方面，在第一方面的一种实现方式中，所述接收第一客户端发送的发布请求之前，所述方法还包括：

[0021] 接收所述第二客户端发送的订阅请求，所述订阅请求携带有所述第一主题的指示信息，所述订阅请求用于请求所述MQTT服务器向所述第二客户端发送所述第一主题对应的数据。

[0022] 根据本申请实施例的通信方法，通过接收第二客户端发送的订阅请求且订阅请求中包括第一主题指示信息，MQTT服务器能够根据第一主题指示信息向第二客户端发送与第一主题对应的数据，其中，MQTT服务器是在第二客户端所属的设备组内获取与第一主题对应的数据能够确保数据发送的安全性以及效率。

[0023] 结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，所述对多个客户端分组包括：

[0024] 确定分组条件，所述分组条件包括被划分至同一设备组的客户端的身份标识所需要满足的条件，其中，一个身份标识能够唯一地指示一个客户端；

[0025] 根据所述多个客户端的身份标识和所述分组条件，对所述多个客户端分组。

[0026] 根据本申请实施例的通信方法，通过使MQTT服务器已知分组条件，即，所述MQTT服务器在获知多个客户端的身份标识后，能够根据客户端的身份标识和分组条件对客户端分组，并且一个身份标识用于唯一指示所述客户端，能够保证客户端分组的准确性。

[0027] 结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，在根据所述多个客户端的身份标识和所述分组条件，对所述多个客户端分组之前，所述方法还包括：

[0028] 接收所述多个客户端中每个客户端发送的所述客户端的标识信息，所述客户端的标识信息用于指示所述客户端的身份标识。

[0029] 根据本申请实施例的通信的方法，通过使MQTT服务器在分组之前，接收与客户端一一对应的标识信息，每个标识信息用于指示所对应的客户端的身份标识，能够保证在分组时明确知道客户端的身份。

[0030] 结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，所述确定所述第一客户端所属的第一设备组包括：

[0031] 根据所述第一客户端的身份标识和所述分组条件，确定所述第一设备组。

[0032] 根据本申请实施例的通信的方法，通过使MQTT服务器根据第一客户端的身份标识和分组条件确定所述第一客户端的所属的第一设备组，能够提高确认第一客户端所属第一设备组的准确性，因为第一客户端的身份标识能够确定所述第一客户端的身份。

[0033] 结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，所述身份标识包括客户端的用户的用户信息或客户端的互联网协议地址。

[0034] 根据本申请实施例的通信的方法，通过使用客户端的用户的用户信息或客户端的互联网协议地址来唯一标识第一客户端的身份，能够准确表示所述第一客户端。

[0035] 结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，在所述MQTT服务器对多个客户端分组之前，所述方法还包括：

[0036] 确定所述多个客户端中的每个客户端允许被划分至设备组。

[0037] 根据本申请实施例的通信的方法，在MQTT服务器对多个客户端分组之前确定多个客户端中的每个客户端允许被划分至设备组，能够使得本申请的通信方法与之前不分组的通信方法兼容，即，不允许划分设备组的客户端可以沿用传统的MQTT协议进行消息转发。

[0038] 结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，所述确定所述多个客户端中的每个客户端允许被划分至设备组，包括：

[0039] 接收所述多个客户端中每个客户端发送的分组标记，每个分组标记用于指示所对应的客户端是否允许被划分至设备组。

[0040] 根据本申请实施例的通信的方法，通过使MQTT服务器接收分组标记，根据分组标记判断所述客户端是否支持分组，若所述客户端支持分组，则按照上述分组方法分组，若是客户端不支持分组则按照传统的MQTT协议进行消息处理。

[0041] 结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，所述分组标记承载于连接请求消息，其中，所述连接请求消息用于请求与所述MQTT服务器建立连接。

[0042] 根据本申请实施例的通信的方法，通过使分组标记承载于请求连接消息能够节省消息的开销。

[0043] 结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，所述分组标记占用所述连接请求消息的固定报头第一个字节中的至少一个比特位。

[0044] 根据本申请实施例的通信的方法，通过使分组标记占用所述连接请求消息的固定报头第一个字节中的至少一个比特位能够与传统的MOTT协议兼容。

[0045] 第二方面，提供了一种通信方法，应用于MQTT客户端，该通信方法包括：

[0046] 向MQTT服务器发送连接请求消息，所述连接请求消息用于请求与所述MQTT服务器建立连接，所述连接请求消息包括分组标记；

[0047] 接收所述MQTT服务器发送的连接确认消息，所述连接确认消息用于确认所述MQTT服务器已经和所述MQTT客户端建立连接，所述连接确认消息包括所述MQTT服务器为所述MQTT客户端分配的设备组标识。根据本申请实施例的通信方法，通过使MQTT客户端向MQTT服务器发送连接请求时携带分组标记，MQTT服务器能够根据分组标记和预设的分组条件对客户端分组，并将客户端所述的设备组的标识信息携带在连接确认消息中告知客户端所属设备组，能够在后续进行消息处理时以设备组为单元进行消息转发，提高了消息转发的效率和安全性。

[0048] 结合第二方面，在第二方面的一种实现方式中，所述分组标记占用所述连接请求消息的固定报头第一个字节中的至少一个比特位。根据本申请实施例的通信方法，通过使分组标记携带在连接请求消息的固定报头中能够与传统的MOTT协议兼容。

[0049] 结合第二方面及其上述实现方式，在第二方面的另一种实现方式中，所述方法还包括：

[0050] 接收所述MQTT服务器发送的发布消息，所述发布消息包括所述设备组标识。

[0051] 根据本申请实施例的通信的方法，通过使MQTT客户端接收的发布消息包括设备组标识，客户端能够得知发布消息的客户端所属的设备组，提高了消息发布的安全性。

[0052] 第三方面，提供了一种通信装置，该装置可以用来执行第一方面及第一方面的任意可能的实现方式中的第一通信设备的操作。具体地，通信装置包括用于执行上述第一方面所描述的步骤或功能相对应的部件(means)可以是第一方面的第一通信设备。所述步骤或功能可以通过软件实现，或硬件实现，或者通过硬件和软件结合来实现。

[0053] 第四方面，提供了一种通信装置，该装置可以用来用于执行第二方面及第二方面的任意可能的实现方式中的第二通信设备的操作。具体地，该装置可以包括用于执行上述第二方面所描述的步骤或功能相对应的部件(means)。所述步骤或功能可以通过软件实现，或硬件实现，或者通过硬件和软件结合来实现。

[0054] 第五方面，提供了一种通信设备，包括，处理器，存储器，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得该通信装置执行第一或第二方面中任一种可能实现方式中的通信方法。

[0055] 可选地，所述处理器为一个或多个，所述存储器为一个或多个。

[0056] 可选地，所述存储器可以与所述处理器集成在一起，或者所述存储器与处理器分离设置。

[0057] 可选的，该通信设备还包括，发射机(发射器)和接收机(接收器)。

[0058] 一个可能的设计中，提供了一种通信设备，包括收发器、处理器和存储器。该处理器用于控制收发器收发信号，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得该通信设备执行第一方面或第一方面任一种可能实现方式中的方法。

[0059] 另一个可能的设计中，提供了一种通信设备，包括收发器、处理器和存储器。该处理器用于控制收发器收发信号，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得该通信设备执行第二方面或第二方面任一种可能实现方式中的方法。

[0060] 第六方面，提供了一种系统，所述系统包括上述通信装置。

[0061] 第七方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序(也可以称为代码，或指令)，当所述计算机程序被运行时，使得计算机执行上述第一方面或第二方面中任一种可能实现方式中的方法。

[0062] 第八方面，提供了一种计算机可读介质，所述计算机可读介质存储有计算机程序(也可以称为代码，或指令)当其在计算机上运行时，使得计算机执行上述第一方面或第二方面中任一种可能实现方式中的方法。

[0063] 第九方面，提供了一种芯片系统，包括存储器和处理器，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得安装有该芯片系统的通信设备执行上述第一方面或第二方面中任一种可能实现方式中的方法。

[0064] 本发明实施例的通信方法、通信装置和通信设备，通过首先对与所述MQTT服务器相连接的客户端分组，再将第一客户端发送的数据，在第一客户端所属的第一设备组内将数据进行转发，或者，接收第二客户端的订阅请求，在第二客户端所属的第一设备组内获取与订阅主题相关的数据，将数据发送给第二客户端，能够提高数据转发的效率以及安全性。

附图说明

[0065] 图1是本申请的一种应用场景图；

[0066] 图2是一种聚合消息处理模式示意图；

[0067] 图3是本申请中一实施例提供的通信方法的示意性框图；

[0068] 图4是本申请设备组的划分流程示意图；

[0069] 图5是MQTT主题订阅树的示意图；

[0070] 图6是以设备组身份标识号作为根的订阅树的示意图；

[0071] 图7是本申请中所述MQTT服务器内部结构示意图；

[0072] 图8是本申请分组流程交互示意图；

[0073] 图9是本申请分组订阅流程交互示意图；

[0074] 图10是本申请分组发布流程交互示意图；

[0075] 图11是本申请实施例提供的一种通信装置的结构示意图；

[0076] 图12是本申请实施例提供的另一种通信装置的结构示意图。

具体实施方式

[0077] 下面先对MQTT协议中的概念做简单的介绍。

[0078] MQTT协议中订阅者即为消息消费者，发布者则是消息生成者，订阅者和发布者之间通过访问控制列表(access control list，ACL)、主题名(topic name，TN)简称为主题(topic)以及主题过滤器(topic filter，TF)来建立“联系”，对MQTT协议来说，不管是消息生成者，还是消息消费者，都统称为客户端。

[0079] MQTT消息订阅与发布基于主题名和主题过滤器实现，因此主题在MQTT中是订阅双方的桥梁，十分重要，关于主题名和主题过滤器的概念如下：

[0080] 主题名：消息发布的主题，是“明确”的主题，不能使用通配符。

[0081] 主题过滤器：消息订阅的主题，可以包含特殊的通配符，允许你一次订阅多个主题。

[0082] MQTT中有一个主题层级的概念，主题是一个结构化、多层的结构，每一层称为主题层级(topic level)，主题层级之间使用主题层级分隔符(‘/’)连接起来，例如：

[0083] myhome/groundfloor/livingroom/temperature

[0084] 客户端可以根据上述主题层级发布消息也可以根据上述主题过滤器订阅相应的主题内容。

[0085] 主题过滤器通过匹配主题名完成消息订阅，当主题过滤器包含通配符时，主题的分层结构能够实现主题的分层订阅，即订阅某一主题层级下的所有主题消息，MQTT提供了两种通配符机制，如下:

[0086] 多层通配符(multi-level wildcard)：数字标志(‘#’)是用于匹配主题中任意层级的通配符。多层通配符表示它的父级和任意数量的子层级。多层通配符位于它自己的层级或者跟在主题层级分隔符后面。不管哪种情况，它都是主题过滤器的最后一个字符。

[0087] 多层通配符匹配示例如下：

[0088] myhome/groundfloor/#

[0089] 各个示例主题及其匹配结果如下：

[0090] myhome/groundfloor/livingroom/temperature

[0091] myhome/groundfloor/kitchen/temperature

[0092] myhome/groundfloor/kitchen/brightness

[0093] 单层通配符(single-level wildcard)：加号(‘+’)是只能用于单个主题层级匹配的通配符。在主题过滤器的任意层级都可以使用单层通配符，包括第一个和最后一个层级。然而它占据过滤器的整个层级。可以在主题过滤器中的多个层级中使用它，也可以和多层通配符一起使用。

[0094] 单层通配符匹配示例如下：

[0095] myhome/groundfloor/+/temperature

[0096] 示例主题匹配结构如下：

[0097] myhome/groundfloor/livingroom/temperature

[0098] myhome/groundfloor/kitchen/temperature

[0099] 为了便于维护订阅者与发布者的关系，MQTT提供了两种订阅模式：

[0100] 精确订阅：仅订阅某个客户端(终端)产生的消息。例如，个人通过手机App订阅家庭内的传感器消息。该场景下主题过滤器等同于主题名，即上述的主题名和主题过滤器一致。

[0101] 模糊订阅：订阅所有终端(通过ACL控制权限)产生的消息。例如，物联网应用(电力供应商)订阅所有用户的设备消息。模糊订阅的订阅者主题过滤器中包括上述的通配符的一种或两种。

[0102] 下面将结合附图，对本申请中的技术方案进行描述。

[0103] 图1是本申请的一种应用场景图，该场景包括客户端110，物联网网关120，MQTT服务器130，云服务140和对象150，下面对这五个部分进行详细地介绍。

[0104] 客户端110(如图1所示包括客户端110a-客户端110f)是使用MQTT协议的客户端，包括使用MQTT协议的程序或设备，其中，使用MQTT协议的程序可以是在任意设备上运行的代码。客户端110通过网络连接到MQTT服务器130，负责采集数据并发布到所述MQTT服务器130。根据应用场景的不同有些客户端可以直接通过MQTT协议连接MQTT服务器，有些客户端需要通过网关连接MQTT服务器。

[0105] 本申请中，对客户端110具体为哪些设备不做限制，以家里的家电为例，可以是照明系统、温度控制系统、水流控制系统等，也可以是用户所使用的手机、移动电脑或个人电脑等。

[0106] 客户端110的功能包括：

[0107] 发布应用消息给其他相关的客户端，例如，家电将相关信息上传；

[0108] 订阅以请求相关的应用消息，例如，用户通过手机查看家里相关信息；

[0109] 取消订阅以移除接受应用消息的请求；

[0110] 从MQTT服务器断开连接。

[0111] 物联网网关120(如图1所示包括物联网网关120a和物联网网关120b)，充当传感器的接入网关，在MQTT协议中，网关(gateway)可以是一个桥(bridge)模式的MQTT服务器(MQTT server)，当客户端可以直接与MQTT服务器130相连接时，物联网网关也可以是一种客户端。

[0112] MQTT服务器130(如图1所示包括服务器130a和服务器130b)，MQTTserver负责消息的订阅与发布。本申请中，所述MQTT服务器可以是程序或者硬件服务器，或者是程序和硬件服务器的结合。MQTT服务器130基于TCP/IP协议进行通信，默认绑定1833端口，也可以绑定其他指定的端口，本申请对此不限制。同时，多个MQTT server可以组成集群，与集群内的各个MQTT server成员相连的客户端能够同步订阅消息，即客户端可以通过与其直连的服务器订阅集群内与其他服务器直连的客户端的消息。此外，MQTT server可以作为客户端接入上一级的MQTT server，即上述bridge模式。在这种模式中，MQTT server根据配置把消息发布到指定的主题，或从上一级MQTT server中订阅消息然后发布给自己的客户端。因此，MQTT server可根据需要配置多个通信接口，MQTT server内部可以分为多个模块。

[0113] MQTT服务器130的功能包括：

[0114] 接受来自客户端的网络连接；

[0115] 接受客户端发布的应用消息；

[0116] 处理客户端的订阅和取消订阅请求；

[0117] 转发应用消息给符合条件的客户端订阅。

[0118] 云服务140，用于处理所述MQTT服务器130对客户端110产生的消息进行汇聚、统计等计算处理后的消息，例如将处理后的消息发送给第三方，其中，第三方包括其他应用(application，APP)或者用户或者其他页面，本申请对此并不限制。

[0119] 对象150(如图1所示包括对象150a和对象150b)，用于接收云服务140发送的数据，可以是网络设备或者应用端。本申请对云服务140处理和处理后数据的发送的对象150不做限制。

[0120] 现有的基于图1所示的MQTT协议的系统架构下，MQTT服务器的主要功能是处理客户端产生的消息，进行汇聚、统计等计算处理后呈现给用户或者第三方应用，把处理结果作为输入进入下一步的处理流程，这种扇入(fan in)的消息处理方式构成了一种聚合的消息处理模式。

[0121] 图2是一种聚合消息处理模式示意图，该示意图包括发布客户端210，MQTT服务器220，订阅客户端230，下面对这三个部分进行详细地介绍。

[0122] 发布客户端210(如图2所示包括发布客户端210a-发布客户端210c)，用于向MQTT服务器220发布消息。

[0123] MQTT服务器220，用于处理发布客户端210发布的消息，例如，进行汇聚、统计等计算处理。

[0124] 订阅客户端230，用于从MQTT服务器订阅消息，其中，订阅客户端发送的订阅请求消息中的主题过滤器可以包含通配符(单层通配符或多层通配符)，用于订阅某一类发布客户端210所发布的消息。

[0125] 基于此模式下的订阅方式，所有客户端消息通过topic匹配无差别推送，这种订阅发布机制虽然实现多对一的消息发布/订阅机制，但是由于没有客户端分组机制，所有的设备均可以无差别订阅与发布消息，这样就会相对的降低了消息通信的安全性，同时通过topic进行消息推送，需要维护一个topic树，对于不同的设备，不同含义的消息需要对topic进行严格区分，这样当物联网中存在设备海量时，topic树的规模也会相对的变得很大，降低消息转发性能。

[0126] 随着物联网技术的发展，在物联网中存在的设备越来越多，继续采用图2所示的消息处理方式无法满足消息处理的性能要求，例如，消息通信的安全性以及消息处理的效率等。因此本申请提出一种通信方法能够在物联网中设备海量时仍然能够满足消息处理的性能要求。

[0127] 图3是本申请中一实施例提供的通信的方法的示意性框图。包括S100-S300三个步骤，下面分别对这三个步骤进行详细的描述。

[0128] S100，MQTT服务器对客户端分组。

[0129] 所述MQTT服务器对多个客户端分组，得到至少两个设备组，所述至少两个设备组的每个设备组中包括至少两个客户端。

[0130] 可选地，客户端向所述MQTT服务器发送连接请求时，发送能够表示所述客户端是否支持分组机制的分组标记，所述MQTT服务器根据分组标记判断发送连接请求的客户端是否支持分组。本申请中，分组标记可以是携带在连接请求的保留位中，也可以是另外发送给所述MQTT服务器的，本申请对此不做限制。此外，每个客户端的分组标记还可以是所述MQTT服务器通过网络规划获知的，此时，客户端不需要发送该分组标记。

[0131] 客户端向所述MQTT服务器发送连接请求时，发送能够表示所述客户端身份的身份标识，可选地，本申请中所述MQTT服务器可以接收所述多个客户端中每个客户端发送的所述客户端的标识信息，所述客户端的标识信息用于指示所述客户端的身份标识。当客户端支持分组时，所述MQTT服务器根据每个客户端的身份标识将客户端划分为不同的设备组，不同的设备组中的客户端满足不同的分组条件，分组条件由预设的分组规则规定，其中，分组规则是所述MQTT服务器已知的，例如，可以是管理员下发的也可是网络规划的时候设定好的，本申请对此并不限定。

[0132] 可选地，上述标识信息可以是客户端的用户的用户名称(user name)、客户端的用户的用户身份标识号(Identity，ID)或者客户端的互联网协议(Internet Protocol，IP)地址，这些标识信息都可以用来唯一确定客户端的身份，本申请对此并不限定，上述身份标识也可以是其他能够表示客户端的身份的信息。

[0133] 可选地，所述MQTT服务器根据预设的分组规则将连接的客户端分组，得到至少两个设备组，所述至少两个设备组的每个设备组中包括至少两个客户端。

[0134] 可选地，所述MQTT服务器将每个设备组的ID作为各自设备组中订阅树的根节点，生成订阅树，基于每一个设备组中的订阅树去维护对应设备组中订阅关系，以提高维护效率。

[0135] 可选地，所述MQTT服务器将每个设备组的ID发送给属于该设备组的每个客户端，例如，携带在连接确认消息中让每个客户端可以在发送消息时指定所属的设备组，所述MQTT服务器也可以不发送设备组的ID，在接收到客户端的消息时通过与客户端之间的连接判断客户端所属的设备组，本申请对此不做限制。

[0136] S200，所述MQTT服务器接收客户端发送的发布/订阅请求消息。

[0137] 可选地，所述MQTT服务器接收客户端发送的发布请求，所述发布请求用于请求所述MQTT服务器发布所述发布请求中的数据，或者，所述MQTT服务器接收客户端发送的订阅请求，所述订阅请求携带有订阅主题的指示信息，所述订阅请求用于请求所述MQTT服务器向所述客户端发送与所述订阅主题对应的数据。

[0138] S300，所述MQTT服务器处理发布/订阅请求消息。

[0139] 可选地，所述MQTT服务器在接收客户端发送的发布请求后，根据S100中的分组，确定发送发布请求的客户端所在的设备组，仅向所述发送发布请求的客户端所在的设备组中订阅了上述数据的订阅客户端发送发布消息，其中，发布消息包括所述发布请求中的数据，可选地，发布消息还可以包括上述设备组的标识，或者，所述MQTT服务器在接收客户端发送的订阅请求后根据S100中的分组，确定发送订阅请求的客户端所在的设备组，在所述发送订阅请求的客户端所在的设备组中匹配与订阅请求中携带主题相对应的数据，并将上述与主题相对应的数据发送给所述订阅客户端，可选地，MQTT服务器还可以将上述设备组的标识信息发送给所述订阅客户端。

[0140] 为了方便本申请以下具体实施例的描述，首先对本申请实施例中涉及到的报文类型和报文的内容进行一个系统的介绍。

[0141] 首先介绍本申请中与客户端身份标识和分组标记相关的连接报文(client request to connect to server，CONNECT)，CONNECT是由客户端向服务端发送的请求连接消息，包括固定报头、可变报头以及有效载荷三个部分，下面对传统的MQTT协议中CONNECT报文进行介绍。

[0142] 1、固定报头。

[0143] CONNECT报文的固定报头构成，如表1所示：

[0144] 表1 CONNECT固定报头

[0145]

[0146] 第一字节的高四位为0001低四位为保留位，传统的MQTT协议中CONNECT报文的固定报头第一字节的低四位默认为0，即任意一位保留位均可以使用。

[0147] 高四位为0001表示消息的类型为CONNECT。传统的MQTT协议中固定报头的第一字节用于表示消息类型和保留字段，消息类型由高四位表示，可以代表16种消息类型，如表2所示：

[0148] 表2 消息类型

[0149]

[0150]

[0151] 2、可变报头。

[0152] CONNECT的可变报头分为四个部分：协议名(protocol name)、协议等级(protocol level)、连接标记(connect flags)、保持连接(keep alive)。不同版本的MQTT协议存在不同的协议名和协议等级。如果MQTT服务器发现协议名不正确的话，就断开连接。如果是协议等级不对应，返回一个码告知客户端。

[0153] 连接标记里面包括用户名标记(user name flag)、密码标记(password flag)、遗嘱保留(will retain)、清理会话(clean session)、保留(reserved)等。它们的位置如表3所示：

[0154] 表3 CONNECT连接标记

[0155]

[0156] 本申请中当身份标识为上述的客户端的用户的用户身份标识号(Identity，ID)时，与表3可变报头的连接标记部分中的用户名标记(user name flag)相关。

[0157] 用户名标记(user name flag)：

[0158] user name flag用于标示在有效载荷里有没有相关的部分。比如。当就用户名标示为1的时候，那就是说明有效载荷部分里面有用户名的信息。

[0159] 3、有效载荷。

[0160] CONNECT消息的有效载荷根据可变头部中各标记位的置位情况，包含一个或多个UTF-8编码字符串。本申请中介绍有效载荷中的客户端的用户的用户身份标识号和用户名字符串。

[0161] 客户端的用户的用户ID：

[0162] 这是第1个UTF编码字符串。客户端的用户的用户ID(Client ID)的长度为1至23个字符，服务器根据客户端的用户的用户ID可以指定到唯一的客户端，因此，本申请中MQTT server可以根据用户ID确定客户端身份，并以此对客户端分组。对于连接到某个MQTT server的所有客户端，它们的用户ID都是唯一的。

[0163] 用户名：

[0164] 如果在表3中用户名标记被置位，则用户名将是有效载荷中的一个字符串。用户名字段用于认证，标明了连接的用户的名字，本申请中MQTT server也可以根据客户端用户的用户名确定客户端身份，并以此对客户端分组。

[0165] 其次介绍本申请中与向客户端发送设备组ID相关的连接确定报文(CONNACK)，CONNACK是由所述MQTT服务器向客户端发送的响应请求连接的连接响应消息，包括固定报头、可变报头两个部分，下面对传统的MQTT协议中CONNACK报文进行介绍。

[0166] 1、固定报头。

[0167] CONNACK报文的固定报头构成，如表4所示：

[0168] 表4 CONNACK固定报头

[0169]

[0170] 第一字节的高四位为0010低四位为保留位，传统的MQTT协议中CONNACK报文的固定报头第一字节低四位与CONNECT报文的固定报头的第一字节低四位值相同。本申请中，当客户端支持分组机制，并在CONNECT报文的固定报头的第一字节低四位中携带有分组标志，则CONNACK报文的固定报头第一字节低四位需要同步发生变化。

[0171] 第一字节的高四位为0010表示消息的类型为CONNACK。

[0172] 2、可变报头。

[0173] CONNACK可变报头的构成，如表5所示：

[0174] 表5 CONNACK可变报头

[0175]

[0176] 本申请以分组标记携带在CONNECT的固定报头中为例，说明如何判断客户端是否支持分组机制，从表1中可以看出CONNECT的固定报头中低四位为保留位，传统的MQTT协议中低四位默认为0，即任意一位空余位置均可以使用，例如：

[0177] 可选地，本申请中可以用第0个比特位作为分组标记，例如，第0个比特位的值为1时表示客户端支持设备组机制，第0个比特位的值为1时表示客户端不支持设备组机制，不支持设备组机制的客户端支持MQTT原有的消息订阅和发布机制，可以是精确订阅或者模糊订阅。

[0178] 可选地，本申请中也可以用第1个比特位作为分组标记，如上所述第1个比特位的值为1时表示客户端支持设备组机制。

[0179] 可选地，本申请中也可以用第2个比特位作为分组标记，如上所述第2个比特位的值为1时表示客户端支持设备组机制。

[0180] 可选地，本申请中也可以用第3个比特位作为分组标记，如上所述第3个比特位的值为1时表示客户端支持设备组机制。

[0181] 可选地，本申请中也可以用第0和1个比特位作为分组标记，如上所述第0和1个比特位的值均为1时表示客户端支持设备组机制。

[0182] 可选地，本申请中也可以用第0和2个比特位作为分组标记，如上所述第0和2个比特位的值均为1时表示客户端支持设备组机制。

[0183] 还有其他用低四位的值表示客户端支持设备组机制的形式，这里不进行一一列举，只要是低四位值中有至少一位与传统的MQTT协议中低四位默认值不同，即可表示客户端支持设备组机制。

[0184] 应理解，使用传统的MQTT协议CONNECT的固定报头中保留位中至少一位作为分组标记位，只是本申请的一个实施例，本申请中使用保留位可以与传统的MQTT协议兼容并且节省了信息开销，但是其他指示分组标记的信息也在本申请的保护范围之内。

[0185] 可选地，服务器可以将设备组的设备组标识发送给客户端，例如，本申请以服务器向客户端发送的设备组标识携带在CONNACK报文的可变报头中为例，说明如何通知客户端所属的设备组。服务器发送CONNACK报文以响应从客户端收到的CONNECT报文。服务器发送给客户端的第一个报文是CONNACK，如果客户端在合理的时间内没有收到服务器的CONNACK报文，客户端应该关闭网络连接。合理的时间取决于应用的类型和通信基础设施。从表5中可以看出CONNACK的可变报头中第二字节为连接返回码，本申请中，客户端支持分组机制时，CONNACK的固定报头第一字节的低四位保留位的值会同步CONNECT的固定报头第一字节的低四位的值，CONNACK可变报头可以在连接返回码后面带上发送CONNECT的客户端的设备组标识，本申请中CONNACK可变报头的保留位是不加修改的。

[0186] 应理解，使用传统的MQTT协议CONNACK的可变报头在连接返回码后面带上发送CONNECT的客户端所属的设备组的设备组标识，只是本申请的一个实施例，本申请中使用连接返回码可以与传统的MQTT协议兼容并且节省了信息开销，但是其他携带客户端所属的设备组的设备组标识的信息也在本申请的保护范围之内。

[0187] 图4是本申请设备组的划分流程示意图。在本申请实施案例中，采用客户端的用户名称作为身份标识，基于user name进行客户端的分组划分，客户端与服务器建立连接时，服务器需要通过客户端鉴权机制保证客户端的合法性，基于user name下发分组规则，在一定程度上保证只有合法的客户端才能参与设备组的划分，具体划分流程如图4所示，包括S110-S150以及S131六个步骤，下面对这六个步骤进行详细的描述。

[0188] S110，客户端向服务器发送连接请求消息。

[0189] 客户端向服务端设备发送CONNECT消息，其中，CONNECT报文的固定报头中携带有分组标记，其中分组标记用于判断客户端是否支持设备组机制，CONNECT报文的有效载荷部分携带有身份标识，其中身份标识用于唯一指定客户端的身份，例如，身份标识可以是user name，CONNECT报文的有效载荷跟CONNECT报文的可变报头的一些标记相关。

[0190] 可选地，本实施例以发送CONNECT报文的固定报头格式如表6所示为例：

[0191] 表6 CONNECT固定报头

[0192]

[0193] 由上文中描述的本申请中可以作为分组标记的可能可知，低四位中有至少一位与传统MQTT协议中的CONNECT报文的固定报头低四位默认值不一致时，认为发送CONNECT的客户端支持设备组机制，即，服务器可以对其分组。

[0194] 可选地，本实施例以发送CONNECT报文的可变报头中用户名标记位置1为例，即，CONNECT报文的有效载荷用户名部分是有效载荷中的一个字符串，用户名字段用于标明连接的客户端的用户的名字。

[0195] 可选地，本实施例以user name作为身份标识，能够在本申请对客户端逻辑设备组分离的基础上进一步增强MQTT消息分发的安全性，因为控制访问列表可以基于客户端的user name进行鉴权操作保证客户端的合法性。

[0196] S120，服务器对客户端鉴权。

[0197] 客户端与服务器建立连接时，需要通过客户端鉴权机制保证客户端的合法性，本实施例基于user name下发设备组划分规则，在一定程度上保证只有合法的客户端才能参与设备组的划分。

[0198] S130，服务器检查客户端是否支持分组。

[0199] 服务器接收到客户端发送的CONNECT连接请求消息之后，本实施例中服务器根据CONNECT报文的固定报头中低四位的值。可得到发送CONNECT连接请求消息的客户端是否支持分组机制。

[0200] 以上述CONNECT报文的固定报头格式为例，服务器在接收到CONNECT连接请求消息之后，能够得知固定报头的第一字节低四位中第0比特位的值为1与传统的MQTT协议的CONNECT报文的固定报头的第一字节低四位中第0比特位的默认值不一致，则服务器可得到发送CONNECT的客户端支持分组机制，按照预设分组规则对客户端分组。其中，预设分组规则本实施例中可以是服务器管理员根据user name制定的，例如，规定user name为A1、A2、A3的客户端为一个设备组，所属设备组的设备组标识为身份标识码(Identity，ID)规定为ID1，规定user name为B1、B2、B3的客户端为一个设备组，所属设备组的ID为ID2等。

[0201] 可选地，本实施例中当上述CONNECT报文的固定报头格式与传统的MQTT协议的CONNECT报文的固定报头格式一致时，则可得到发送CONNECT的客户端不支持分组机制。当不支持分组机制时，默认客户端为公共组，其发布的消息能够被所有订阅客户端订阅。

[0202] S131，生成MQTT主题订阅树。

[0203] 可选地，本实施例中当客户端不支持分组机制时，即，服务器无法对客户端分组，则对于客户端后续的消息发布以及消息订阅采用现有的发布或者订阅机制。如图5所示，其中，T1、T2.....等为主题名称，图5是现有的生成MQTT主题订阅树的示意图，所有的订阅关系都是通过一颗订阅树来维护，在订阅树中，topic将被按照“/”组织成树状结构，如图5所示的订阅树，其中订阅树的每个节点都是一个topic分级，每个节点对应的topic就是从根节点到当前节点所组成的topic。

[0204] S140，服务器指定客户端所属的设备组的设备组标识。

[0205] 可选地，本实施例中当客户端支持分组机制时，服务器根据预先设定的分组机制对客户端分组，并指定客户端所在设备组的设备组标识，本实施例中，可选地，例如客户端的user name为A1则根据上述分组规则，客户端指定该客户端所属设备组的设备组标识为ID1。

[0206] S150，服务器以设备组标识作为订阅树的根。

[0207] 可选地，本实施例中以设备组ID作为订阅树的根，维护所述设备组内的订阅关系。如图6所示，T2、T21.....等为主题名称，图6是以设备组ID作为根节点的订阅树的示意图，则在不同的设备组中可以有相同主题的消息发布，因为不同组间相互独立的，增强了消息发布的灵活性，并且在各个小组中进行消息的发布或者订阅，降低了主题树的检索规模，提高了消息推送效率。

[0208] 本申请中，支持分组机制的客户端根据user name分组并以每个设备组的设备组ID作为订阅树的根后，划分设备组流程结束；不支持分组机制的客户端根据现有的以主题名称作为订阅树的根节点，划分流程结束。

[0209] 当连接建立成功以后，基于同一设备组ID的客户端构成一个隔离的物联网络，服务器对在同一个物联网络内的客户端进行消息订阅和消息推送，并允许客户端在消息发送时指定设备组ID，可以进行设备组间的消息推送。

[0210] 应理解，本申请中该实施例以CONNECT报文的固定报头低四位的第0比特位作为分组标记以及以客户端user name作为身份标识。只是为了说明划分流程而列举出的参数实例，其他的可以作为分组标记以及身份标识的信息，例如，客户端向服务器发送的其他信息携带有分组标记以及身份标识也在本申请的保护范围之内。

[0211] 图7是本申请中MQTT服务器内部结构示意图，包括访问控制列表310，持久服务模块320，会话管理模块330，订阅服务模块340，发布服务模块350，数据包管理模块360，数据包引擎370，其中，与现有MQTT服务器不同的是本申请中MQTT服务器增加了数据包引擎360和数据包引擎370，用于实现对客户端分组的功能。

[0212] 下面对这七个部分进行详细地介绍。

[0213] 访问控制列表(access control list，ACL)310，用于负责客户端接入认证与操作鉴权，客户端连接时提供用户名密码或证书，ACL模块对客户端进行认证，认证通过后把客户端的会话(session)保存在会话管理(session manager)模块中。

[0214] 客户端操作时，ACL对操作执行鉴权，主要包含发布、订阅这两个操作，ACL需要校验客户端对发布、订阅的主题(topic)是否有访问(读、写)的权限，如果没有权限则拒绝该操作，否则转到对应的服务模块执行操作处理。

[0215] 持久服务模块(persistent service)320，用于负责消息、session、客户端等信息的持久化。

[0216] 会话管理模块(session manager)330，用于负责客户端session的管理，当客户端断连后重连时，只要session在有效期内，session manager可以根据其session恢复其订阅，并重新下发断连期间新的消息。

[0217] 订阅服务模块(subscribe service)340，用于处理消息订阅请求的服务部件，当客户端提交订阅请求时，依照MQTT的订阅处理逻辑进行处理：遍历该订阅过滤器中的主题层级，挂到订阅树对应的节点上。最后把该订阅客户端挂到最后一层主题层级对应节点的客户端列表中。

[0218] 发布服务模块(publish service)350，用于处理消息发布的服务部件，当客户端发布消息时，ACL鉴权通过后，发布服务模块进行发布消息的转发。该部件包含三个功能：

[0219] 根据发布消息的QoS、保留(retain)标识及订阅情况进行处理包括以下几种情况：

[0220] 如果是retain消息，需要调用persistent service把消息持久化；

[0221] 如果是QoS>0的消息，除了做一遍QoS＝0的操作之外，还需要把消息保存一段时间，在订阅客户端临时断连后重新连接时再做一次订阅恢复及派发。

[0222] 发布服务模块中还包括主题匹配模块(topic matcher)用于处理遍历订阅树，把发布主题与订阅过滤器进行匹配，把消息派发给匹配成功的订阅客户端。

[0223] 发布服务模块中还包括标签匹配模块(tags matcher)用于处理发布、订阅客户端的标签，标签的匹配处理包括：

[0224] 在topic matcher匹配结束后，得到匹配成功的主题过滤器及其对应的客户端列表；

[0225] 遍历这些客户端列表，如果客户端订阅时设定支持标签意识(tag-aware)，则调用标签引擎(tags engine)执行，匹配成功把消息派发给该客户端；否则，默认订阅方式是不支持tag-aware，则不需要处理，直接把消息派发给该客户端。

[0226] 数据包管理模块(packet manager)360作为session manager的补充，提供了客户端数据包(packet)属性的管理服务，在本申请中，数据包管理模块用于维护分组信息，例如，当前有哪些设备组分别对应哪些分组规则，图4中所述的，规定user name为A1、A2、A3的客户端为一个设备组，所属设备组的设备组标识为身份标识码(Identity，ID)规定为ID1，规定user name为B1、B2、B3的客户端为一个设备组，所属设备组的ID为ID2，所述A1属于ID1的分组信息可以由数据包管理模块管理。

[0227] 数据包引擎(packet engine)370，用于执行packet分组的规则引擎，根据packet分组规则，对连接的客户端分组划分，匹配分组，检索分组订阅树，本申请中的数据包引擎是分组动作的执行，根据制定规则执行分组动作，例如，数据包管理模块获取了分组规则规定A1属于ID1的信息，数据包引擎可以根据分组信息将A1划分到ID1。

[0228] 应理解，图7是服务器内部具体结构示意图，可以是一个程序包含的多个功能模块，各个模块在程序内部有相同或不同的进程、线程负责执行，所以对于本申请来说服务器执行发布/订阅消息的处理，可以是执行一个或多个程序，本申请对此并不限定。本申请中的服务器也可以仅仅包括发布/订阅服务模块和数据包管理模块以及数据包引擎，仅完成分组发布/订阅，可以不对客户端鉴权，也可以不包括持久服务模块和会话管理模块，本申请中对ACL310、persistent service320以及session manager330不做详细的介绍，下面重点介绍本申请中在分组机制的下，服务器的发布/订阅服务模块和数据包管理模块以及数据包引擎是如何完成对客户端分组，并在设备组内进行消息处理的。

[0229] 应理解，图7是服务器内部具体结构示意图，包括简单的服务器内部执行功能模块，对于与客户端之间的消息交互，可以是现有技术中的通信模块完成，例如，通信模块可以用于接收或发送消息，这里介绍服务器内部具体结构时不涉及。

[0230] 图8是本申请分组流程交互示意图。包括S210-S230以及S221-S222五个步骤，下面对这五个步骤进行详细的描述。

[0231] S210，客户端向服务器发送连接请求消息。

[0232] 客户端向服务器发送连接请求消息CONNECT，其中，CONNECT携带有分组标记，服务器可以根据分组标记判断客户端是否支持分组。

[0233] S220，服务器检查客户端是否支持设备组机制。

[0234] 服务器的MQTT服务器数据包管理模块根据CONNECT中的分组标记检查客户端是否支持分组。

[0235] S221，服务器与客户端建立连接。

[0236] 客户端不支持分组机制时，服务器根据CONNECT与客户端建立连接，并进行接下来的消息发布和消息订阅。

[0237] S222，服务器确定客户端支持分组。

[0238] 客户端支持分组机制时，服务器的数据包引擎单元按照分组规则对客户端分组。

[0239] S230，服务器与客户端建立连接。

[0240] 支持分组机制的客户端在分组之后与服务器建立连接。

[0241] 本申请中的MQTT服务器与客户端在建立连接时，会根据客户端在连接请求消息中携带的分组标记确认客户端是否支持分组机制，在客户端支持分组机制时对客户端分组，能够在后续基于设备组进行消息发布/订阅提高了消息处理的效率和安全性。

[0242] 图9是本申请分组订阅流程交互示意图。本实施例中客户端在成功发送CONNECT消息，并得到服务器端授权允许建立彼此连接的CONNACK消息之后，客户端发送订阅请求消息(subscribe message)，订阅感兴趣的topic主题列表(至少一个主题)。

[0243] 图9包括S310-S350五个步骤，下面对这五个步骤进行详细的描述。

[0244] S310，订阅客户端向服务器发送订阅请求消息。

[0245] 消息订阅客户端向服务器的订阅服务模块(subscribe service)发送订阅请求消息(subscribe message)，其中，subscribe message包含包标识符和订阅列表，包标识符是客户端和服务器之间的唯一标识符，用于标识消息流中的某个消息。订阅消息可以包含对某个客户端的任意数量消息的订阅，每个订阅都是由一对主题和QoS级别组成。订阅消息的主题还可以包含通配符，这使得订阅客户端可以订阅特定的主题模式。如果对一个客户端有重叠订阅，则代理服务器将使用该主题的最高QoS级别传递消息。

[0246] 本申请中，对订阅消息的包标识符和订阅列表不做限制，可以为任意一种订阅消息。

[0247] S320，服务器检查客户端的分组情况。

[0248] 服务器的数据包管理器(packet manager)对客户端的数据包属性进行管理服务，检查订阅客户端的分组情况。

[0249] 本申请中，客户端向服务器发起连接请求时，即，发送CONNECT时，会携带身份标识和分组标记，服务器根据分组标记会判断客户端是否支持分组，根据身份标识将客户端指定在一个设备组内。

[0250] 本申请中，当客户端订阅消息时，服务器会根据建立连接时的消息再次判断发送订阅消息的客户端是否支持分组，以及所属的设备组。

[0251] S330，服务器确定客户端所属的设备组。

[0252] 服务器的数据包引擎(packet engine)执行客户端的数据包分组，根据分组规则分组。

[0253] 本申请中，客户端向服务器发送订阅消息时，例如客户端支持分组则数据包引擎会为客户端匹配分组信息，将客户端划分到对应的设备组。

[0254] S340，客户端分组订阅。

[0255] 本申请中，客户端被划分到所属的设备组后，会在所属设备组内订阅消息，服务器以设备组ID为根目录生成订阅树。

[0256] S350，客户端订阅成功。

[0257] 服务器的订阅服务模块根据以设备组ID为根目录的订阅树，遍历该客户端订阅过滤器中的主题层级，挂到订阅树对应的节点上。最后把该订阅客户端挂到最后一层主题层级对应节点的客户端列表中，完成订阅过程。服务器会向订阅客户端发送订阅应答(SUBACK)消息。

[0258] 本实施例中，给出的是支持分组的客户端订阅流程，若是不支持分组的客户端订阅消息，直接是服务器的订阅服务模块响应，不会经过数据包管理器和数据包引擎分组。

[0259] 图10是本申请分组发布流程交互示意图。包括S410-S450五个步骤，下面对这五个步骤进行详细的描述。

[0260] 本申请中在MQTT进行消息发布时，需要根据分组结果发布，传统的MQTT协议的发布(PUBLISH)报文第一字节的第一比特位与第二比特位均为1时为保留位，本申请中可以将所述保留位作为设备组标识位，若保留位为真，即，上述第一比特位与第二比特位均为1，则消息发布可以在PUBLISH报文的可变报头中指定设备组ID。PUBLISH报文的固定报头格式，如表7所示：

[0261] 表7 PUBLISH固定报头

[0262]

[0263] S410，发布客户端向服务器发送发布请求消息。

[0264] 消息发布客户端向服务器发送发布请求消息(publish message)，其中，publish message携带有主题信息。

[0265] S420，服务器检查发布客户端分组情况。

[0266] 服务器中的数据包管理器(packet manager)对客户端的数据包属性进行检查，判断发布客户端分组情况。

[0267] 本申请中，客户端向服务器发起连接请求时，即，发送CONNECT时，会携带身份标识和分组标记，客户端根据分组标记会判断客户端是否支持分组，根据身份标识将客户端指定在一个设备组内。

[0268] 本申请中，当客户端发布消息时，服务器会根据建立连接时的消息再次判断发送发布消息的客户端是否支持分组，以及所属的设备组,可选地，发布客户端向服务器发送的PUBLISH报文的可变报头中指定设备组ID时，服务器可以根据发布客户端指定的设备组ID获取发布客户端所属设备组信息。

[0269] S430，服务器检查发布客户端对应的订阅树。

[0270] 服务器中的数据包引擎(packet engine)执行客户端的数据包分组，根据分组规则分组划分，匹配分组，并检查发布客户端对应设备组的订阅树。

[0271] 本申请中，客户端向服务器发送发布消息时，例如客户端支持分组则数据包引擎会为客户端匹配分组信息，将客户端划分到对应的设备组，并检查对应设备组的订阅树。

[0272] S440，服务器根据发布消息进行主题匹配。

[0273] 服务器中的主题匹配器根据发布客户端发送的发布消息，在发布客户端所属的设备组中进行主题匹配。

[0274] 本申请中，服务器在对客户端分组之后，将发布的消息在所述的设备组中推送，判断同一个设备组中有没有客户端订阅响应主题消息，进行主题匹配，将消息推送出去。

[0275] S450，服务器将发布消息转发给对应的订阅客户端。

[0276] 服务器连接发布客户端与订阅客户端，将订阅客户端订阅的相匹配的主题消息从发布客户端接收过来，并转发给同一个设备组中与订阅了对应的发布主题的订阅客户端。

[0277] 本实施例中，给出的是支持分组的客户端发布消息流程，若是不支持分组的客户端发布消息，与传统发布流程一样不会经过数据包管理器和数据包引擎分组。

[0278] 应理解，本实施例中订阅客户端和发布客户端只是举例说明的形式，在MQTT协议中，客户端可以是订阅客户端和/或发布客户端，本申请对此并不限制。

[0279] 图11是本申请中一种通信装置的结构示意图，包括分组单元410，接收单元420，确定单元430和发送单元440，下面对这四个部分进行详细的介绍。

[0280] 服务器的分组单元410，其中，可选地，服务器的分组单元410，可以用于对多个客户端分组，得到至少两个设备组，所述至少两个设备组的每个设备组中包括至少两个客户端。分组单元还用于确定分组条件，所述分组条件包括被划分至同一设备组的客户端的身份标识所需要满足的条件，其中，一个身份标识能够唯一地指示一个客户端；根据所述多个客户端的身份标识和所述分组条件，对所述多个客户端。

[0281] 例如，可以是图7中的数据包管理模块和数据包引擎单元完成的，其中，数据包管理模块用于管理分组信息，不同的设备组所对应的分组规则，确定客户端所属的设备组，而数据包引擎用于执行分组，所以，应理解本申请中分组单元可以是图7中的数据包管理模块和数据包引擎合作完成的，而数据包管理模块和数据包引擎可以是一个模块的两个功能也可以是多个模块，本申请对此并不限制。

[0282] 服务器的接收单元420，其中，可选地，服务器的接收单元420，可以用于接收第一客户端发送的发布请求，所述发布请求包括第一数据，所述第一数据对应第一主题，所述发布请求用于请求服务器发布所述第一数据。

[0283] 接收单元420还可以接收第二客户端发送的订阅请求，订阅请求携带有第一主题的指示信息，订阅请求用于请求MQTT服务器向第二客户端发送第一主题对应的数据。

[0284] 接收单元420还可以接收多个客户端中每个客户端发送的分组标记，每个分组标记用于指示所对应的客户端是否允许被划分至设备组。。

[0285] 例如，本申请中接收单元420可以是MQTT服务器与客户端相互通信的模块执行的。

[0286] 服务器的确定单元430，其中，可选地，确定单元430，可以用于从所述至少两个设备组中确定所述第一客户端所属的第一设备组，仅向所述第一设备组内的至少一个第二客户端发送发布消息，其中，发布消息包括上述第一数据，发布消息还可以包括上述第一设备组的设备组标识，或者，确定单元，可以用于从所述至少两个设备组中确定所述第二客户端所属的第一设备组，并确定第一数据，所述第一数据来自所述第一设备组中至少一个客户端，所述第一数据与所述第一主题相对应。例如，确定单元430，可以是图7中的数据包管理模块和数据包引擎单元完成的，其中，数据包管理模块用于管理分组信息，不同的设备组所对应的分组规则，确定客户端所属的设备组，而数据包引擎用于根据数据包管理模块管理的分组规则确定分组。

[0287] 服务器的发送单元440，其中，可选地，发送单元440，可以用于向上述第二客户端发送所述发布消息。例如，确定单元440，可以是MQTT服务器与客户端相互通信的模块执行的。

[0288] 可选地，本申请中，上述410-440四个部分可以是服务器一个功能模块具有的四种功能。本申请对此不做限制。

[0289] 图12是本申请中另一种通信装置的结构示意图，包括发送单元510和接收单元520两个部分，下面对这两个部分进行详细的介绍。

[0290] 客户端发送单元510，可选地，本申请中客户端发送单元510可以用于向服务器发送连接请求消息、发布消息或订阅消息。

[0291] 客户端接收单元520，可选地，本申请中客户端接收单元520可以用于接收服务器发送的连接确认消息或发布消息。

[0292] 可选地，本申请中，上述510-520两个部分可以是客户端一个功能模块具有的两种功能。本申请对此不做限制。

[0293] 以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。