WO2019141111A1 - 通信方法和通信装置 - Google Patents

通信方法和通信装置 Download PDF

Info

Publication number
WO2019141111A1
WO2019141111A1 PCT/CN2019/070838 CN2019070838W WO2019141111A1 WO 2019141111 A1 WO2019141111 A1 WO 2019141111A1 CN 2019070838 W CN2019070838 W CN 2019070838W WO 2019141111 A1 WO2019141111 A1 WO 2019141111A1
Authority
WO
WIPO (PCT)
Prior art keywords
client
message
device group
clients
request
Prior art date
Application number
PCT/CN2019/070838
Other languages
English (en)
French (fr)
Inventor
崔高生
程宝传
林乐
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP19740907.1A priority Critical patent/EP3734913A4/en
Publication of WO2019141111A1 publication Critical patent/WO2019141111A1/zh
Priority to US16/928,204 priority patent/US11411897B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
    • H04L51/046—Interoperability with other network applications or services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services

Definitions

  • the present application relates to the field of communications, and more particularly to a communication method and communication device in the field of communications.
  • the MQTT protocol was originally developed as an instant messaging protocol developed by International Business Machines Corporation (IBM).
  • the MQTT protocol is a client/server architecture publish/subscribe mode messaging protocol designed to be lightweight and open. Simple, standardized, and easy to implement principles. It is based on Transmission Control Protocol/Internet Protocol (TCP/IP) or other ordered, reliable, two-way network connections and provides simple, lightweight publish/subscribe features. Making it a good choice for many scenarios, especially for restricted environments such as machine-to-machine (M2M) and Internet of Things (IoT), thus being Widely used in the Internet of Things, mobile Internet, such as cars, smart cities, industrial 4.0, smart home, medical care and so on.
  • TCP/IP Transmission Control Protocol/Internet Protocol
  • IoT Internet of Things
  • the MQTT protocol is a protocol designed for the communication of remote sensors and control devices with limited computing power and working in low-bandwidth unreliable networks. It has the following basic features:
  • QoS quality of service
  • the application provides a communication method and communication device, which can improve the efficiency and security of the MQTT server processing message publishing/subscription.
  • a communication method is provided, which is applied to a message queue telemetry transmission MQTT server, the method comprising: grouping a plurality of clients to obtain at least two device groups, each device group of the at least two device groups Include at least two clients;
  • the MQTT server groups the clients, the client is divided into different device groups, and after receiving the first data sent by the first client, the MQTT server determines that the first client belongs to The first device group forwards the publishing message to the second client in the first device group, and the publishing message includes the first data, where the second client may be one or more devices, and the publishing message may also be
  • the communication method of the embodiment of the present application can determine that the data sent by the first client is forwarded to the second client that belongs to the same device group, ensuring the security of message forwarding, and for the MQTT server. Message forwarding within a device group can improve the efficiency of message forwarding.
  • the method before the receiving the sending request sent by the first client, the method further includes:
  • the MQTT server by receiving the subscription request sent by the second client, and the first topic indication information is included in the subscription request, the MQTT server can send the second topic to the second client according to the first topic indication information.
  • the data, wherein the MQTT server acquires data corresponding to the first topic in the device group to which the second client belongs can ensure the security and efficiency of data transmission.
  • the grouping the multiple clients includes:
  • Determining a grouping condition the grouping condition including a condition to be satisfied by an identity of a client divided into the same device group, wherein one identity can uniquely indicate a client;
  • the client by making the MQTT server aware of the grouping condition, that is, after the MQTT server learns the identity of the plurality of clients, the client can be grouped according to the identity and grouping conditions of the client, and one The identity is used to uniquely indicate the client and can ensure the accuracy of the client grouping.
  • the method also includes:
  • the MQTT server receives the identification information corresponding to the client one by one before the grouping, and each identification information is used to indicate the identity of the corresponding client, which can ensure that the grouping is clear. Know the identity of the client.
  • Determining the first device group according to the identity of the first client and the grouping condition.
  • the first device group to which the first client belongs can be improved.
  • the accuracy because the identity of the first client is able to determine the identity of the first client.
  • the identity identifier includes user information of a user of the client or an internet protocol address of the client.
  • the first client can be accurately represented by uniquely identifying the identity of the first client by using the user information of the user of the client or the Internet Protocol address of the client.
  • the method before the MQTT server groups the multiple clients, the method further includes:
  • each of the plurality of clients is allowed to be divided into device groups.
  • the communication method of the embodiment of the present application before the MQTT server groups the plurality of clients, it is determined that each of the plurality of clients is allowed to be divided into the device group, and the communication method of the present application can be made not previously grouped.
  • the communication method is compatible, that is, the client that does not allow the device group to be divided can perform message forwarding using the traditional MQTT protocol.
  • the determining, by the determining, that each of the multiple clients is allowed to be allocated to a device group includes:
  • each packet tag is used to indicate whether the corresponding client is allowed to be divided into device groups.
  • the MQTT server receives the packet tag, and determines whether the client supports the packet according to the packet tag. If the client supports the packet, the packet is grouped according to the foregoing grouping method, if the client does not support The packet is processed according to the traditional MQTT protocol.
  • the packet marking is carried in a connection request message, where the connection request message is used to request to establish a connection with the MQTT server.
  • the overhead of the message can be saved by causing the packet tag to be carried in the request connection message.
  • the packet tag occupies at least one bit in a first byte of a fixed header of the connection request message.
  • the packet marking can be compatible with the conventional MOTT protocol by occupying at least one bit in the first byte of the fixed header of the connection request message.
  • a communication method which is applied to an MQTT client, and the communication method includes:
  • connection request message is used to request to establish a connection with the MQTT server, and the connection request message includes a grouping mark;
  • connection confirmation message is used to confirm that the MQTT server has established a connection with the MQTT client
  • the connection confirmation message includes the MQTT server allocating the MQTT client Device group ID.
  • the MQTT server can group the client according to the packet tag and the preset grouping condition, and the device described by the client The identification information of the group is carried in the connection confirmation message to inform the device group to which the client belongs, and can forward the message in the device group as a unit in the subsequent message processing, thereby improving the efficiency and security of message forwarding.
  • the packet tag occupies at least one of the first byte of the fixed header of the connection request message. According to the communication method of the embodiment of the present application, it is compatible with the conventional MOTT protocol by causing the packet tag to be carried in the fixed header of the connection request message.
  • the method further includes:
  • the client by enabling the release message received by the MQTT client to include the device group identifier, the client can know the device group to which the client that issued the message belongs, which improves the security of message issuance.
  • a communication device that can be used to perform the operations of the first communication device in the first aspect and any possible implementation of the first aspect.
  • the communication device comprises a first communication device for performing the steps or functions described in the first aspect above, which may be the first aspect.
  • the steps or functions may be implemented by software, or by hardware, or by a combination of hardware and software.
  • a communication device for use in performing the operations of the second communication device in any of the possible implementations of the second aspect and the second aspect.
  • the apparatus may comprise means for performing the steps or functions described in the second aspect above.
  • the steps or functions may be implemented by software, or by hardware, or by a combination of hardware and software.
  • a communication device comprising: a processor, a memory for storing a computer program, the processor for calling and running the computer program from a memory, such that the communication device performs the first or second A communication method in any of the possible implementations.
  • the processor is one or more, and the memory is one or more.
  • the memory may be integrated with the processor or the memory may be separate from the processor.
  • the communication device further includes a transmitter (transmitter) and a receiver (receiver).
  • a communication device in one possible design, includes a transceiver, a processor, and a memory.
  • the processor is for controlling a transceiver transceiver signal for storing a computer program for calling and running the computer program from the memory, such that the communication device performs the first aspect or any of the possible implementations of the first aspect The method in .
  • a communication device in another possible design, includes a transceiver, a processor, and a memory.
  • the processor is for controlling a transceiver transceiver signal for storing a computer program for calling and running the computer program from the memory, such that the communication device performs either the second aspect or the second aspect The method in .
  • a system comprising the communication device described above.
  • a computer program product comprising: a computer program (which may also be referred to as a code, or an instruction) that, when executed, causes the computer to perform the first aspect or A method in any of the possible implementations of the two aspects.
  • a computer program (which may also be referred to as a code, or an instruction) that, when executed, causes the computer to perform the first aspect or A method in any of the possible implementations of the two aspects.
  • a computer readable medium storing a computer program (which may also be referred to as code, or instructions), when executed on a computer, causes the computer to perform the first aspect or A method in any of the possible implementations of the two aspects.
  • a ninth aspect provides a chip system including a memory and a processor for storing a computer program for calling and running the computer program from the memory, such that the communication device mounted with the chip system performs the above The method of any of the possible implementations of the first aspect or the second aspect.
  • the communication method, the communication device, and the communication device of the embodiment of the present invention by first grouping the client connected to the MQTT server, and then transmitting the data sent by the first client to the first device group to which the first client belongs
  • the data is forwarded, or the subscription request of the second client is received, the data related to the subscription topic is acquired in the first device group to which the second client belongs, and the data is sent to the second client, which can improve data forwarding. Efficiency and security.
  • 2 is a schematic diagram of an aggregate message processing mode
  • FIG. 3 is a schematic block diagram of a communication method provided by an embodiment of the present application.
  • FIG. 4 is a schematic diagram of a division process of a device group of the present application.
  • FIG. 5 is a schematic diagram of an MQTT topic subscription tree
  • FIG. 6 is a schematic diagram of a subscription tree with a device group identity number as a root
  • FIG. 7 is a schematic diagram showing the internal structure of the MQTT server in the present application.
  • FIG. 8 is a schematic diagram of interaction of a grouping process of the present application.
  • FIG. 9 is a schematic diagram of interaction of a packet subscription process of the present application.
  • FIG. 10 is a schematic diagram of interaction of a packet distribution process of the present application.
  • FIG. 11 is a schematic structural diagram of a communication apparatus according to an embodiment of the present disclosure.
  • FIG. 12 is a schematic structural diagram of another communication apparatus according to an embodiment of the present application.
  • the subscriber is the message consumer, and the publisher is the message producer.
  • the access control list (ACL) and the topic name (TN) are referred to as the subject (subject) between the subscriber and the publisher.
  • ACL access control list
  • TN topic name
  • Topic topic filter
  • client both the message producer and the message consumer are collectively referred to as the client.
  • Topic name The subject of the message release, which is a "clear” theme, and cannot use wildcards.
  • Theme Filter The subject of a message subscription that can contain special wildcards that allow you to subscribe to multiple topics at once.
  • the theme is a structured, multi-layered structure. Each layer is called a topic level.
  • the topic levels are connected by a topic level separator ('/'), for example. :
  • the client can post messages according to the above-mentioned topic level or subscribe to the corresponding topic content according to the above topic filter.
  • the topic filter completes the message subscription by matching the topic name.
  • the topic filter contains wildcards
  • the hierarchical structure of the topic enables hierarchical subscription of the topic, that is, subscribe to all topic messages under a certain topic level.
  • MQTT provides two wildcards. The mechanism is as follows:
  • Multi-level wildcard A numeric sign (‘#’) is a wildcard used to match any level in a topic.
  • a multi-layer wildcard represents its parent and any number of sub-levels.
  • a multi-level wildcard is at its own level or follows the topic hierarchy separator. In either case, it is the last character of the theme filter.
  • Single-level wildcard The plus sign (‘+’) is a wildcard that can only be used for a single topic level match.
  • Single-level wildcards can be used at any level of the theme filter, including the first and last levels. However it occupies the entire hierarchy of filters. It can be used in multiple hierarchies in the theme filter, or with multi-layer wildcards.
  • the example topic matching structure is as follows:
  • MQTT provides two subscription modes:
  • Precise subscription Subscribe only to messages generated by a client (terminal). For example, an individual subscribes to sensor messages within a home via a mobile app.
  • the theme filter in this scenario is equivalent to the topic name, that is, the above topic name and theme filter are consistent.
  • Fuzzy subscription Subscribe to messages generated by all terminals (through ACL control permissions). For example, an IoT application (electricity provider) subscribes to device messages for all users.
  • the subscriber profile filter of the fuzzy subscription includes one or both of the above wildcards.
  • FIG. 1 is an application scenario diagram of the present application, which includes a client 110, an Internet of Things gateway 120, an MQTT server 130, a cloud service 140, and an object 150. These five sections are described in detail below.
  • the client 110 (including the client 110a-client 110f as shown in FIG. 1) is a client using the MQTT protocol, and includes a program or device using the MQTT protocol, wherein the program using the MQTT protocol can be run on any device. Code.
  • the client 110 is connected to the MQTT server 130 via a network and is responsible for collecting data and publishing it to the MQTT server 130.
  • some clients can connect to the MQTT server directly through the MQTT protocol.
  • Some clients need to connect to the MQTT server through the gateway.
  • the device 110 is not limited to the specific device, and the home appliance is taken as an example, and may be a lighting system, a temperature control system, a water flow control system, or the like, or a mobile phone, a mobile computer, or an individual used by the user. Computer, etc.
  • the functions of the client 110 include:
  • Subscribe to request related application messages for example, the user views relevant information on the home through the mobile phone;
  • the Internet of Things gateway 120 (including the Internet of Things gateway 120a and the Internet of Things gateway 120b as shown in FIG. 1) serves as an access gateway for the sensor.
  • the gateway can be a bridge mode MQTT server ( MQTT server), when the client can directly connect with the MQTT server 130, the IoT gateway can also be a client.
  • the MQTT server 130 (including the server 130a and the server 130b as shown in FIG. 1) is responsible for subscription and distribution of messages.
  • the MQTT server may be a program or a hardware server, or a combination of a program and a hardware server.
  • the MQTT server 130 communicates based on the TCP/IP protocol. It is bound to the port 1833 by default, and can also be bound to other designated ports. This application does not limit this.
  • multiple MQTT servers can form a cluster. Clients connected to each MQTT server member in the cluster can synchronize subscription messages. That is, the client can subscribe to the client's messages directly connected to other servers in the cluster through the server directly connected to it.
  • the MQTT server can be used as a client to access the upper level MQTT server, that is, the above bridge mode.
  • the MQTT server posts the message to the specified topic according to the configuration, or subscribes to the message from the upper MQTT server and then publishes it to its own client. Therefore, the MQTT server can configure multiple communication interfaces as needed, and the MQTT server can be divided into multiple modules.
  • the functions of the MQTT server 130 include:
  • the cloud service 140 is configured to process the message that the MQTT server 130 performs aggregation, statistics, and the like on the message generated by the client 110, for example, sending the processed message to a third party, where the third party includes other applications (application , APP) or user or other pages, this application is not limited to this.
  • the object 150 (including the object 150a and the object 150b as shown in FIG. 1) is configured to receive data sent by the cloud service 140, and may be a network device or an application end.
  • the present application does not limit the object 150 to which the cloud service 140 processes and processes the transmitted data.
  • the main function of the MQTT server is to process the message generated by the client, perform calculation processing such as aggregation and statistics, and present it to the user or a third-party application, and take the processing result as an input.
  • this fan in message processing constitutes an aggregated message processing mode.
  • FIG. 2 is a schematic diagram of an aggregated message processing mode, which includes a publishing client 210, an MQTT server 220, and a subscription client 230. These three sections are described in detail below.
  • the publishing client 210 (including the publishing client 210a - publishing client 210c as shown in FIG. 2) is configured to issue a message to the MQTT server 220.
  • the MQTT server 220 is configured to process the message issued by the publishing client 210, for example, performing calculation processing such as aggregation, statistics, and the like.
  • the subscription client 230 is configured to subscribe to the message from the MQTT server, wherein the topic filter in the subscription request message sent by the subscribing client may include a wildcard (single layer wildcard or multi-layer wildcard) for subscribing to a certain type of publishing client. 210 published messages.
  • this subscription publishing mechanism implements a many-to-one message publishing/subscription mechanism, all devices can be free because there is no client grouping mechanism. Differentially subscribe and publish messages, which will reduce the security of message communication. At the same time, the topic pushes through the topic. A topic tree needs to be maintained. For different devices, messages with different meanings need to be strictly distinguished from the topic. When there are a large number of devices in the Internet of Things, the size of the topic tree will become relatively large, reducing the message forwarding performance.
  • the message processing method shown in Figure 2 can not be used to meet the performance requirements of message processing, such as the security of message communication and the efficiency of message processing. . Therefore, the present application proposes a communication method capable of meeting the performance requirements of message processing when the device in the Internet of Things is massive.
  • FIG. 3 is a schematic block diagram of a method for communication provided by an embodiment of the present application. The three steps of S100-S300 are included, and the three steps are described in detail below.
  • the MQTT server groups the clients.
  • the MQTT server groups multiple clients to obtain at least two device groups, and each device group of the at least two device groups includes at least two clients.
  • the MQTT server determines, according to the packet tag, whether the client that sends the connection request supports the packet.
  • the packet marking may be carried in the reserved bit of the connection request, or may be additionally sent to the MQTT server, which is not limited in this application.
  • the packet marking of each client may also be learned by the MQTT server through network planning. At this time, the client does not need to send the packet marking.
  • the client When sending a connection request to the MQTT server, the client sends an identity that can indicate the identity of the client.
  • the MQTT server in the application can receive the client sent by each of the multiple clients.
  • the identification information of the client where the identifier information of the client is used to indicate the identity of the client.
  • the MQTT server divides the client into different device groups according to the identity of each client, and the clients in different device groups meet different grouping conditions, and the grouping condition is determined by the preset grouping rule. It is provided that the grouping rule is known to the MQTT server, for example, it may be set by the administrator or set by the network, and is not limited in this application.
  • the identifier information may be a user name of a user of the client, a user identity number (Identity, ID) of the user of the client, or an Internet Protocol (IP) address of the client, where the identifier information is It can be used to uniquely determine the identity of the client, which is not limited in this application.
  • the above identity may also be other information that can indicate the identity of the client.
  • the MQTT server groups the connected clients according to a preset grouping rule to obtain at least two device groups, and each device group of the at least two device groups includes at least two clients.
  • the MQTT server uses the ID of each device group as the root node of the subscription tree in the respective device group to generate a subscription tree, and maintains a subscription relationship in the corresponding device group based on the subscription tree in each device group to improve Maintenance efficiency.
  • the MQTT server sends the ID of each device group to each client belonging to the device group, for example, carried in a connection confirmation message, so that each client can specify the device group to which the message belongs when sending the message.
  • the MQTT server may also not send the ID of the device group, and determine the device group to which the client belongs by connecting with the client when receiving the message of the client. This application does not limit this.
  • the MQTT server receives a publish/subscribe request message sent by a client.
  • the MQTT server receives a publishing request sent by a client, where the publishing request is used to request the MQTT server to publish data in the publishing request, or the MQTT server receives a subscription request sent by a client,
  • the subscription request carries indication information of a subscription topic, and the subscription request is used to request the MQTT server to send data corresponding to the subscription topic to the client.
  • the MQTT server processes a publish/subscribe request message.
  • the MQTT server determines, according to the packet in S100, the device group where the client that sends the publishing request is located, and only sends the device group where the client that sends the request is located.
  • the subscription client that subscribes to the above data sends a publish message, where the publish message includes data in the publish request, and optionally, the publish message may further include the identifier of the device group, or the MQTT server receives the client.
  • the device group in which the client that sends the subscription request is located is determined according to the packet in the S100, and the data corresponding to the subject in the subscription request is matched in the device group in which the client that sends the subscription request is located.
  • the data corresponding to the topic is sent to the subscribing client.
  • the MQTT server may further send the identifier information of the device group to the subscribing client.
  • the client request to connect to server (CONNECT) related to the client identity and the packet identifier is introduced in the present application.
  • CONNECT is a request connection message sent by the client to the server, including a fixed header and a variable header. And the three parts of the payload, the following describes the CONNECT message in the traditional MQTT protocol.
  • the fixed header of the CONNECT message is composed as shown in Table 1:
  • the upper four bits of the first byte are 0001 and the lower four bits are reserved bits.
  • the lower four bits of the first byte of the fixed header of the CONNECT message default to 0, that is, any one of the reserved bits can be used.
  • the upper four bits are 0001 indicating that the message type is CONNECT.
  • the first byte of the fixed header in the traditional MQTT protocol is used to indicate the message type and reserved field.
  • the message type is represented by the upper four bits and can represent 16 message types, as shown in Table 2:
  • variable header of CONNECT is divided into four parts: protocol name, protocol level, connect flags, and keep alive. Different versions of the MQTT protocol have different protocol names and protocol levels. If the MQTT server finds that the protocol name is incorrect, it disconnects. If the protocol level does not correspond, return a code to inform the client.
  • connection tag includes a user name flag, a password flag, a will retain, a clean session, a reserved, and the like. Their location is shown in Table 3:
  • the user name flag is used to indicate if there is any relevant part in the payload. such as.
  • the user name is marked as 1, it is the information indicating the user name in the payload part.
  • the payload of the CONNECT message contains one or more UTF-8 encoded strings according to the setting of each flag bit in the variable header.
  • the user identification number and username string of the user of the client in the payload are described in this application.
  • the user ID (Client ID) of the client is 1 to 23 characters in length.
  • the server can be assigned to a unique client according to the user ID of the client. Therefore, the MQTT server in this application can determine the client identity based on the user ID. And use this to group clients. For all clients connected to an MQTT server, their user IDs are unique.
  • the username tag is set in Table 3, the username will be a string in the payload.
  • the username field is used for authentication and indicates the name of the connected user.
  • the MQTT server can also determine the identity of the client according to the username of the client user, and group the client by this.
  • connection determination message related to sending the device group ID to the client in the present application.
  • the CONNACK is a connection response message sent by the MQTT server to the client in response to the request request, including a fixed header and a variable header. Two parts, the following describes the CONNACK message in the traditional MQTT protocol.
  • the fixed header of the CONNACK packet is composed as shown in Table 4:
  • the upper four bits of the first byte are 0010 and the lower four bits are reserved bits.
  • the lower four bits of the first byte of the fixed header of the CONNACK message are lower than the first byte of the fixed header of the CONNECT message.
  • the values are the same.
  • the client supports the packet mechanism and carries the packet flag in the lower four bits of the first byte of the fixed header of the CONNECT message
  • the lower four bits of the first byte of the fixed header of the CONNACK message need to be synchronized. Variety.
  • the upper four bits of the first byte are 0010 indicating that the message type is CONNACK.
  • composition of the CONNACK variable header is shown in Table 5:
  • This application takes a packet tag in the fixed header of the CONNECT as an example to illustrate how to determine whether the client supports the packet mechanism. It can be seen from Table 1 that the lower four bits of the CONNECT fixed header are reserved bits, and the traditional MQTT protocol is low. The four bits default to 0, which means that any one of the free positions can be used, for example:
  • the 0th bit can be used as the grouping mark in the present application.
  • the client supports the device group mechanism, and the value of the 0th bit indicates the client.
  • the device does not support the device group mechanism.
  • the client that does not support the device group mechanism supports the original message subscription and publishing mechanism of MQTT, which can be an exact subscription or a fuzzy subscription.
  • the first bit can also be used as a grouping mark in the present application.
  • the client supports the device group mechanism.
  • the second bit can also be used as a grouping mark in the present application.
  • the client supports the device group mechanism.
  • the third bit can also be used as a grouping mark in the present application.
  • the client supports the device group mechanism.
  • the 0th and 1st bits can also be used as the grouping mark in the present application.
  • the client supports the device group mechanism.
  • the 0th and 2nd bits may also be used as the grouping mark in the present application.
  • the client supports the device group mechanism.
  • the lower four bits represent the client-supported device group mechanism. No one is listed here, as long as at least one of the lower four-bit values is different from the lower four-bit default value of the conventional MQTT protocol. This means that the client supports the device group mechanism.
  • the packet marking bit is used as the packet marking bit, which is only one embodiment of the present application.
  • the reserved bits used in the present application can be compatible with the traditional MQTT protocol and save information overhead.
  • other information indicating the grouping mark is also within the scope of the present application.
  • the server may send the device group identifier of the device group to the client.
  • the device group identifier sent by the server to the client is carried in the variable header of the CONNACK packet as an example to describe how to notify the client.
  • the device group to which it belongs. The server sends a CONNACK message in response to the CONNECT message received from the client.
  • the first packet sent by the server to the client is CONNACK. If the client does not receive the CONNACK packet from the server within a reasonable period of time, the client should close the network connection. A reasonable amount of time depends on the type of application and the communication infrastructure. It can be seen from Table 5 that the second byte in the variable header of the CONNACK is the connection return code.
  • the value of the lower four bits of the first byte of the fixed header of the CONNACK will be Synchronize the lower four bits of the first byte of the fixed header of the CONNECT.
  • the CONNACK variable header may carry the device group identifier of the client transmitting the CONNECT after the connection return code. The reserved bit of the CONNACK variable header in this application is not added. Modified.
  • variable header of the traditional MQTT protocol CONNACK is followed by the device group identifier of the device group to which the client transmitting the CONNECT belongs after the connection return code, but only one embodiment of the present application, the connection return code may be used in the present application. It is compatible with the traditional MQTT protocol and saves information overhead, but other information of the device group identifier carrying the device group to which the client belongs is also within the scope of the present application.
  • FIG. 4 is a schematic diagram of a division process of the device group of the present application.
  • the user name of the client is used as the identity identifier, and the client is divided according to the user name.
  • the server needs to ensure the validity of the client through the client authentication mechanism, based on the user name.
  • the grouping rules are issued to ensure that only legal clients can participate in the division of device groups.
  • the specific division process is shown in Figure 4, including six steps of S110-S150 and S131. The following six steps are detailed. description of.
  • the client sends a connection request message to the server.
  • the client sends a CONNECT message to the server device, where the fixed header of the CONNECT message carries a packet tag, where the packet tag is used to determine whether the client supports the device group mechanism, and the payload portion of the CONNECT packet carries the identity identifier.
  • the identity identifier is used to uniquely specify the identity of the client.
  • the identity identifier may be a user name
  • the payload of the CONNECT message is related to some tags of the variable header of the CONNECT message.
  • a fixed header format for sending a CONNECT message is as shown in Table 6 as an example:
  • the client that considers to send the CONNECT is considered to be The device group mechanism is supported, that is, the server can group it.
  • the user name tag position 1 in the variable header of the CONNECT message is sent as an example, that is, the payload user name part of the CONNECT message is a character string in the payload, and the username field is used. Indicates the name of the user of the connected client.
  • the user name is used as the identity identifier in the embodiment, and the security of the MQTT message distribution can be further enhanced on the basis of the separation of the client logical device group in the application, because the control access list can be authenticated based on the user name of the client.
  • the operation guarantees the legitimacy of the client.
  • S120 The server authenticates the client.
  • the client authentication mechanism is required to ensure the legality of the client.
  • the device group is divided according to the user name, and only a legal client can participate in the device group division. .
  • the server checks whether the client supports the grouping.
  • the server in this embodiment After receiving the CONNECT connection request message sent by the client, the server in this embodiment is based on the value of the lower four bits in the fixed header of the CONNECT message. It can be obtained whether the client that sends the CONNECT connection request message supports the grouping mechanism.
  • the server can know that the value of the 0th bit in the lower four bits of the first byte of the fixed header is 1 and the traditional MQTT protocol. If the default value of the 0th bit in the lower 4 bits of the first byte of the fixed header of the CONNECT message is inconsistent, the server may obtain a client support packet mechanism for sending the CONNECT, and group the client according to the preset grouping rule.
  • the preset grouping rule may be determined by the server administrator according to the user name. For example, the client whose user name is A1, A2, and A3 is a device group, and the device group identifier of the device group is the identity identifier.
  • the ID (Identity, ID) is defined as ID1, and the client whose user name is B1, B2, and B3 is a device group, and the ID of the device group to which it belongs is ID2.
  • the client that sends the CONNECT does not support the packet mechanism.
  • the default client is a public group, and its published messages can be subscribed by all subscribing clients.
  • FIG. 5 is a schematic diagram of an existing MQTT topic subscription tree, and all subscription relationships are maintained through a subscription tree in the subscription tree.
  • the topic will be organized into a tree structure according to "/", as shown in the subscription tree in Figure 5, where each node of the subscription tree is a topic hierarchy, and the topic corresponding to each node is from the root node to the current node.
  • the topic that is composed is composed.
  • the server specifies a device group identifier of the device group to which the client belongs.
  • the server groups the client according to the preset grouping mechanism, and specifies the device group identifier of the device group where the client is located.
  • the client name of the client is A1
  • the client specifies the device group ID of the device group to which the client belongs as ID1 according to the above-mentioned grouping rule.
  • the server uses the device group identifier as the root of the subscription tree.
  • the device group ID is used as the root of the subscription tree, and the subscription relationship in the device group is maintained.
  • T2, T21., etc. are the subject names
  • FIG. 6 is a schematic diagram of the subscription tree with the device group ID as the root node, and messages with the same topic may be published in different device groups, because different The groups are independent of each other, which enhances the flexibility of message publishing, and publishes or subscribes to messages in each group, which reduces the retrieval scale of the topic tree and improves the efficiency of message push.
  • the client that supports the grouping mechanism divides the device group process according to the user name group and the device group ID of each device group as the root of the subscription tree; the client that does not support the grouping mechanism according to the existing topic
  • the name is the root node of the subscription tree, and the partitioning process ends.
  • the clients based on the same device group ID form an isolated Internet of Things.
  • the server subscribes to messages and pushes messages to clients in the same IoT network, and allows the client to specify when the message is sent.
  • the device group ID can be used to push messages between device groups.
  • the embodiment uses the 0th bit of the lower four bits of the fixed header of the CONNECT message as the packet tag and the client user name as the identity.
  • the embodiment uses the 0th bit of the lower four bits of the fixed header of the CONNECT message as the packet tag and the client user name as the identity.
  • other information that can be used as a grouping tag and identity for example, other information sent by the client to the server carries the grouping tag and the identity is also within the protection scope of the present application. .
  • FIG. 7 is a schematic diagram of an internal structure of an MQTT server in the present application, including an access control list 310, a persistent service module 320, a session management module 330, a subscription service module 340, a publishing service module 350, a data packet management module 360, and a data packet engine 370.
  • the MQTT server in the present application adds a packet engine 360 and a packet engine 370 for implementing the function of grouping clients.
  • An access control list (ACL) 310 is configured to be responsible for client access authentication and operation authentication.
  • the client provides a username, password, or certificate when the client connects, and the ACL module authenticates the client. After the authentication is passed, the client is authenticated. The session is saved in the session manager module.
  • the ACL When the client operates, the ACL performs authentication on the operation. It mainly includes the two operations of publishing and subscribing. The ACL needs to verify whether the client has access to the published and subscribed topics (read, write). The permission rejects the operation, otherwise it goes to the corresponding service module to perform the operation processing.
  • a persistent service module 320 is used to persist information such as messages, sessions, clients, and the like.
  • the session management module (session manager) 330 is responsible for the management of the client session. When the client is disconnected and reconnected, as long as the session is within the validity period, the session manager can resume its subscription according to its session and re-issue the disconnection. New news during the period.
  • a subscription service module 340 is configured to process a service component of the message subscription request.
  • the client submits the subscription request, the client processes according to the subscription processing logic of the MQTT: traversing the topic hierarchy in the subscription filter and hanging to the subscription tree. On the corresponding node. Finally, the subscription client is hung in the client list of the corresponding node of the last level of the topic level.
  • a publishing service module (350) is configured to process a service component for message publishing. When the client issues a message, after the ACL authentication is passed, the publishing service module forwards the published message. This part contains three functions:
  • the publishing service module also includes a topic matcher for processing the traversal subscription tree, matching the publishing topic with the subscription filter, and dispatching the message to the matching matching client.
  • the publishing service module further includes a tag matcher for processing the tags of the publishing and subscribing clients, and the matching processing of the tags includes:
  • the topic matcher After the topic matcher is matched, the matching topic filter and its corresponding client list are obtained.
  • the packet manager module 360 provides management services for client packet attributes.
  • the packet management module is used to maintain group information, for example, which devices are currently available. Which grouping rules are respectively associated with the groups.
  • the client whose user name is A1, A2, and A3 is a device group, and the device group ID of the device group to which the device group is identified is the identity code (ID).
  • ID the identity code
  • the client whose user name is B1, B2, and B3 is a device group, and the ID of the belonging device group is ID2, and the group information of the A1 belonging to ID1 can be managed by the data packet management module.
  • a packet engine 370 a rule engine for performing packet grouping, grouping the connected clients according to the packet grouping rule, matching the packets, and retrieving the packet subscription tree.
  • the packet engine in this application is a grouping action. Execution, the grouping action is performed according to the rule. For example, the packet management module acquires the information that the grouping rule specifies that A1 belongs to ID1, and the packet engine may divide A1 into ID1 according to the grouping information.
  • FIG. 7 is a schematic diagram of a specific internal structure of a server, which may be a plurality of functional modules included in a program. Each module has the same or different processes and threads in the program, and the thread executes the publish/subscribe for the present application.
  • the processing of the message may be one or more programs, which is not limited in this application.
  • the server in the present application may also include only the publish/subscribe service module and the packet management module and the packet engine, and only complete the packet publish/subscribe, may not authenticate the client, or may not include the persistent service module and the session management module.
  • ACL310, persistent service320 and session manager330 are not introduced in detail. The following focuses on the packet distribution mechanism in this application. How does the server's publish/subscribe service module and packet management module and the packet engine complete the client? End grouping and message processing within the device group.
  • FIG. 7 is a schematic diagram of a specific internal structure of the server, including a simple internal execution function module of the server.
  • the communication module in the prior art can be completed.
  • the communication module can be used for receiving. Or send a message, here is not involved in the specific structure inside the server.
  • FIG. 8 is a schematic diagram of interaction of a grouping process of the present application. The five steps of S210-S230 and S221-S222 are included, and the five steps are described in detail below.
  • the client sends a connection request message to the server.
  • the client sends a connection request message CONNECT to the server, where the CONNECT carries a packet tag, and the server can determine whether the client supports the packet according to the packet tag.
  • S220 The server checks whether the client supports the device group mechanism.
  • the server's MQTT server packet management module checks if the client supports grouping based on the packet tag in CONNECT.
  • the server establishes a connection with the client.
  • the server When the client does not support the grouping mechanism, the server establishes a connection with the client according to CONNECT, and performs subsequent message publishing and message subscription.
  • the server determines that the client supports the grouping.
  • the server's packet engine unit groups the clients according to the grouping rules.
  • the server establishes a connection with the client.
  • Clients that support the packet mechanism establish a connection with the server after grouping.
  • the client checks whether the client supports the grouping mechanism according to the packet tag carried in the connection request message of the client, and groups the client when the client supports the grouping mechanism, which can be followed.
  • Message publishing/subscription based on device groups improves the efficiency and security of message processing.
  • FIG. 9 is a schematic diagram of interaction of a packet subscription process of the present application.
  • the client after the client successfully sends the CONNECT message and obtains the server-side authorization to allow the establishment of the CONNACK message connected to each other, the client sends a subscription message to subscribe to the topic topic list (at least one topic) of interest.
  • Figure 9 includes five steps S310-S350, which are described in detail below.
  • the subscribing client sends a subscription request message to the server.
  • the message subscribing client sends a subscription message to the server's subscription service, where the subscribe message includes a package identifier and a subscription list, and the package identifier is a unique identifier between the client and the server. Used to identify a message in a message flow.
  • a subscription message can contain subscriptions to any number of messages for a client, each subscription consisting of a pair of topics and QoS levels.
  • the subject of the subscription message can also contain wildcards, which allows the subscribing client to subscribe to a particular theme mode. If there is an overlapping subscription to a client, the proxy server will pass the message with the highest QoS level for that topic.
  • the packet identifier and the subscription list of the subscription message are not limited, and may be any one of the subscription messages.
  • the server checks the grouping status of the client.
  • the server's packet manager manages the client's packet attributes and checks the subscribing of the subscribing client.
  • the server determines whether the client supports the packet according to the group tag, and specifies the client in a device group according to the identity identifier.
  • the server when the client subscribes to the message, the server will again judge whether the client that sends the subscription message supports the packet and the device group to which it belongs according to the message when the connection is established.
  • the server determines a device group to which the client belongs.
  • the server's packet engine performs packet processing of the client and is grouped according to the grouping rules.
  • the packet engine matches the packet information for the client, and divides the client into the corresponding device group.
  • the client after the client is divided into its own device group, it will subscribe to the message in its own device group, and the server generates a subscription tree with the device group ID as the root directory.
  • the subscription service module of the server traverses the topic hierarchy in the client subscription filter according to the subscription tree with the device group ID as the root directory, and hangs on the node corresponding to the subscription tree. Finally, the subscription client is hung to the client list of the corresponding layer of the last level of the topic level to complete the subscription process.
  • the server sends a subscription reply (SUBACK) message to the subscribing client.
  • SUPBACK subscription reply
  • the client subscription process supporting the packet is given. If the client does not support the packet subscription message, it is directly the server's subscription service module response, and will not be grouped by the packet manager and the packet engine.
  • FIG. 10 is a schematic diagram of interaction of a packet distribution process of the present application. The five steps of S410-S450 are included, and the five steps are described in detail below.
  • the reserved bit is used.
  • the reserved bit can be used as the device group identifier bit in the application. If the reserved bit is true, that is, the first bit and the second bit are both 1, the message issuance can be specified in the variable header of the PUBLISH message.
  • Device group ID The fixed header format of the PUBLISH message is shown in Table 7:
  • the publishing client sends a publish request message to the server.
  • the message publishing client sends a publish message to the server, wherein the publish message carries the subject information.
  • the server checks the status of the publishing client group.
  • the packet manager in the server checks the client's packet attributes to determine the status of the client group.
  • the client when the client initiates a connection request to the server, that is, when the CONNECT is sent, the identity identifier and the packet tag are carried, and the client determines whether the client supports the packet according to the packet tag, and specifies the client to be a device according to the identity identifier. s.
  • the server judges again whether the client that sends the posted message supports the packet according to the message when the connection is established, and the device group to which it belongs, optionally, the PUBLISH report sent by the client to the server.
  • the server can obtain the device group information of the publishing client according to the device group ID specified by the publishing client.
  • the server checks the subscription tree corresponding to the publishing client.
  • the packet engine in the server performs packet grouping of the client, divides the packets according to the grouping rules, matches the packets, and checks the subscription tree of the corresponding device group of the publishing client.
  • the packet engine matches the packet information for the client, divides the client into the corresponding device group, and checks the subscription tree of the corresponding device group.
  • the server performs topic matching according to the release message.
  • the topic matcher in the server performs topic matching in the device group to which the publishing client belongs according to the publishing message sent by the publishing client.
  • the server pushes the posted message in the device group, determines whether there is a client subscription response topic message in the same device group, performs topic matching, and pushes the message out.
  • S450 The server forwards the publishing message to the corresponding subscription client.
  • the server connects the publishing client and the subscribing client, and the matching topic message subscribed by the subscribing client is received from the publishing client, and forwarded to the subscribing client that subscribes to the corresponding publishing topic in the same device group.
  • a client-sending message flow for supporting a packet is given. If a client that does not support the packet publishes a message, it does not pass the packet manager and the packet engine grouping as in the conventional publishing process.
  • the subscription client and the publishing client in this embodiment are only exemplified.
  • the client may be a subscription client and/or a publishing client, which is not limited in this application.
  • FIG. 11 is a schematic structural diagram of a communication apparatus in the present application, including a grouping unit 410, a receiving unit 420, a determining unit 430, and a transmitting unit 440. These four parts will be described in detail below.
  • a grouping unit 410 of the server wherein, optionally, the grouping unit 410 of the server may be configured to group the plurality of clients to obtain at least two device groups, and each device group of the at least two device groups includes at least Two clients.
  • the grouping unit is further configured to determine a grouping condition, the grouping condition includes a condition that needs to be satisfied by an identity of the client divided into the same device group, wherein one identity identifier can uniquely indicate a client; according to the plurality of clients The identity of the end and the grouping condition for the plurality of clients.
  • the data packet management module and the packet engine unit in FIG. 7 may be completed by the data packet management module and the packet engine unit in FIG. 7, wherein the data packet management module is configured to manage group information, grouping rules corresponding to different device groups, and determine a device group to which the client belongs.
  • the packet engine is used to perform grouping. Therefore, it should be understood that the grouping unit in the present application may be completed by the packet management module and the packet engine in FIG. 7, and the packet management module and the packet engine may be one module.
  • the two functions may also be multiple modules, which is not limited in this application.
  • the receiving unit 420 of the server may be configured to receive a publishing request sent by the first client, where the publishing request includes first data, where the first data corresponds to the first topic,
  • the publish request is used to request the server to publish the first data.
  • the receiving unit 420 can also receive the subscription request sent by the second client, where the subscription request carries the indication information of the first topic, and the subscription request is used to request the MQTT server to send the data corresponding to the first topic to the second client.
  • the receiving unit 420 may further receive a packet tag sent by each of the plurality of clients, where each packet tag is used to indicate whether the corresponding client is allowed to be divided into the device group. .
  • the receiving unit 420 in the present application may be executed by a module in which the MQTT server communicates with the client.
  • a determining unit 430 wherein, optionally, the determining unit 430 is configured to determine, from the at least two device groups, the first device group to which the first client belongs, only to the first device group
  • the at least one second client sends a publishing message, where the publishing message includes the foregoing first data, and the publishing message may further include the device group identifier of the first device group, or a determining unit may be used for the at least two Determining, by the device group, the first device group to which the second client belongs, and determining first data, the first data is from at least one client in the first device group, the first data and the The first theme corresponds.
  • the determining unit 430 may be implemented by the data packet management module and the data packet engine unit in FIG. 7, where the data packet management module is configured to manage group information, grouping rules corresponding to different device groups, and determine the client belongs to The device group, and the packet engine is used to determine the packet according to the grouping rules managed by the packet management module.
  • the sending unit 440 of the server wherein, optionally, the sending unit 440 is configured to send the publishing message to the second client.
  • the determining unit 440 can be executed by a module that the MQTT server and the client communicate with each other.
  • the four parts of the foregoing 410-440 may be four functions that one functional module of the server has. This application does not limit this.
  • FIG. 12 is a schematic structural diagram of another communication apparatus in the present application, which includes two parts, a transmitting unit 510 and a receiving unit 520. The two parts will be described in detail below.
  • the client sending unit 510 may be configured to send a connection request message, a publishing message, or a subscription message to the server.
  • the client receiving unit 520 may be configured to receive a connection confirmation message or a publishing message sent by the server.
  • the above two parts of 510-520 may be two functions that one functional module of the client has. This application does not limit this.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer And Data Communications (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Abstract

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

Description

通信方法和通信装置
本申请要求于2018年1月16日提交中国专利局、申请号为201810038597.7、发明名称为“通信方法和通信装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信领域，更具体地，涉及通信领域中的一种通信方法和通信装置。
背景技术
随着智能硬件和移动互联网技术的快速发展，物联网技术发展迅速，但由于其受限的环境特性，传统的互联网协议越来越难以满足物联网的需要，这主要体现在移动网络代价昂贵、带宽低、可靠性差，而且处理器和内存资源都十分有限，与此同时物联网下海量在线设备产生庞大数据，给云端带来很大的网络开销和处理压力。在这种背景下，消息队列遥测传输(Message Queue Telemetry Transport，MQTT)协议应运而生。
MQTT协议最早是由国际商业机器公司(International Business Machines Corporation，IBM)开发的一个即时通讯协议，MQTT协议是一个客户端/服务器架构的发布/订阅模式的消息传输协议，其设计遵循轻巧、开放、简单、规范、易于实现的原则。其实现基于传输控制协议/因特网互联协议(Transmission Control Protocol/Internet Protocol，TCP/IP)或其他有序、可靠、双向的网络连接，并且提供了简单、轻量级的发布/订阅特性，这些特性使得它对很多场景来说都是很好的选择，特别是对于受限的环境如机器与机器的通信(machine-to-machine，M2M)以及物联网环境(Internet of Things，IoT)，因而被广泛应用在物联网、移动互联网中，例如汽车、智慧城市、工业4.0、智能家居、医疗医护等等。
MQTT协议是为大量计算能力有限，且工作在低带宽不可靠的网络的远程传感器和控制设备通讯而设计的协议，具有以下的几项基本特性：
使用发布/订阅消息模式，提供一对多的消息发布机制，解除应用程序耦合；
对负载内容屏蔽的消息传输；
基于TCP/IP或其他有序、可靠、双向的网络连接实现；
具有三种消息发布服务质量(Quality of service，QoS)：
“至多一次”：消息发布完全依赖底层的TCP/IP网络，尽操作环境所能提供的最大努力分发消息，可能会发送消息丢失或重复，例如，这个等级可用于环境传感器数据，单次的数据丢失没关系，因为不久之后会再次发送；
“至少一次”：确保消息到达，但是消息重复可能会发生；
“只有一次”：确保消息到达且保证消息只到达一次，例如，这个等级可用在一个计费***中，这里如果消息重复或丢失会导致计费***不正确的收费；
小型传输，开销很小，协议交换最小化，以降低网络流量；
使用遗愿(Last Will)和遗嘱(Testament)特性通知有关各方客户端异常终端的机制。
现有的基于MQTT协议的发布/订阅模式，客户端数量很多时消息转发的性能会降低。在物联网技术迅速发展的过程中，客户端的数量会越来越庞大，因此，如何提高消息发布/订阅效率和安全保障成为亟需解决的问题。
发明内容
本申请提供了一种通信方法和通信装置，能够提高MQTT服务器处理消息发布/订阅的效率和安全性。
第一方面，提供了一种通信方法，应用于消息队列遥测传输MQTT服务器，该方法包括：对多个客户端分组，得到至少两个设备组，所述至少两个设备组的每个设备组中包括至少两个客户端；
接收第一客户端发送的发布请求，所述发布请求包括第一数据，所述第一数据对应第一主题，所述发布请求用于请求所述MQTT服务器发布所述第一数据；
确定所述第一客户端所属的第一设备组，并向所述第一设备组内的第二客户端发送发布消息，所述发布消息包括所述第一数据。
根据本申请实施例的通信方法，通过使MQTT服务器对客户端分组，将客户端分成不同的设备组，MQTT服务器在接收到第一客户端发送的第一数据之后，确定第一客户端所属的第一设备组，并将发布消息转发给第一设备组中的第二客户端，发布消息包括所述第一数据，其中，第二客户端可以是一个或者多个设备，且发布消息还可以包括第一设备组的标识，本申请实施例的通信方法能够确定第一客户端发送的数据转发给所属同一设备组的第二客户端，确保了消息转发的安全性，并且对于MQTT服务器来说在一个设备组内进行消息转发可以提高消息转发的效率。
结合第一方面，在第一方面的一种实现方式中，所述接收第一客户端发送的发布请求之前，所述方法还包括：
接收所述第二客户端发送的订阅请求，所述订阅请求携带有所述第一主题的指示信息，所述订阅请求用于请求所述MQTT服务器向所述第二客户端发送所述第一主题对应的数据。
根据本申请实施例的通信方法，通过接收第二客户端发送的订阅请求且订阅请求中包括第一主题指示信息，MQTT服务器能够根据第一主题指示信息向第二客户端发送与第一主题对应的数据，其中，MQTT服务器是在第二客户端所属的设备组内获取与第一主题对应的数据能够确保数据发送的安全性以及效率。
结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，所述对多个客户端分组包括：
确定分组条件，所述分组条件包括被划分至同一设备组的客户端的身份标识所需要满足的条件，其中，一个身份标识能够唯一地指示一个客户端；
根据所述多个客户端的身份标识和所述分组条件，对所述多个客户端分组。
根据本申请实施例的通信方法，通过使MQTT服务器已知分组条件，即，所述MQTT服务器在获知多个客户端的身份标识后，能够根据客户端的身份标识和分组条件对客户端分组，并且一个身份标识用于唯一指示所述客户端，能够保证客户端分组的准确性。
结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，在根据所述多个客户端的身份标识和所述分组条件，对所述多个客户端分组之前，所述方法还包括：
接收所述多个客户端中每个客户端发送的所述客户端的标识信息，所述客户端的标识信息用于指示所述客户端的身份标识。
根据本申请实施例的通信的方法，通过使MQTT服务器在分组之前，接收与客户端一一对应的标识信息，每个标识信息用于指示所对应的客户端的身份标识，能够保证在分组时明确知道客户端的身份。
结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，所述确定所述第一客户端所属的第一设备组包括：
根据所述第一客户端的身份标识和所述分组条件，确定所述第一设备组。
根据本申请实施例的通信的方法，通过使MQTT服务器根据第一客户端的身份标识 和分组条件确定所述第一客户端的所属的第一设备组，能够提高确认第一客户端所属第一设备组的准确性，因为第一客户端的身份标识能够确定所述第一客户端的身份。
结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，所述身份标识包括客户端的用户的用户信息或客户端的互联网协议地址。
根据本申请实施例的通信的方法，通过使用客户端的用户的用户信息或客户端的互联网协议地址来唯一标识第一客户端的身份，能够准确表示所述第一客户端。
结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，在所述MQTT服务器对多个客户端分组之前，所述方法还包括：
确定所述多个客户端中的每个客户端允许被划分至设备组。
根据本申请实施例的通信的方法，在MQTT服务器对多个客户端分组之前确定多个客户端中的每个客户端允许被划分至设备组，能够使得本申请的通信方法与之前不分组的通信方法兼容，即，不允许划分设备组的客户端可以沿用传统的MQTT协议进行消息转发。
结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，所述确定所述多个客户端中的每个客户端允许被划分至设备组，包括：
接收所述多个客户端中每个客户端发送的分组标记，每个分组标记用于指示所对应的客户端是否允许被划分至设备组。
根据本申请实施例的通信的方法，通过使MQTT服务器接收分组标记，根据分组标记判断所述客户端是否支持分组，若所述客户端支持分组，则按照上述分组方法分组，若是客户端不支持分组则按照传统的MQTT协议进行消息处理。
结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，所述分组标记承载于连接请求消息，其中，所述连接请求消息用于请求与所述MQTT服务器建立连接。
根据本申请实施例的通信的方法，通过使分组标记承载于请求连接消息能够节省消息的开销。
结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，所述分组标记占用所述连接请求消息的固定报头第一个字节中的至少一个比特位。
根据本申请实施例的通信的方法，通过使分组标记占用所述连接请求消息的固定报头第一个字节中的至少一个比特位能够与传统的MOTT协议兼容。
第二方面，提供了一种通信方法，应用于MQTT客户端，该通信方法包括：
向MQTT服务器发送连接请求消息，所述连接请求消息用于请求与所述MQTT服务器建立连接，所述连接请求消息包括分组标记；
接收所述MQTT服务器发送的连接确认消息，所述连接确认消息用于确认所述MQTT服务器已经和所述MQTT客户端建立连接，所述连接确认消息包括所述MQTT服务器为所述MQTT客户端分配的设备组标识。根据本申请实施例的通信方法，通过使MQTT客户端向MQTT服务器发送连接请求时携带分组标记，MQTT服务器能够根据分组标记和预设的分组条件对客户端分组，并将客户端所述的设备组的标识信息携带在连接确认消息中告知客户端所属设备组，能够在后续进行消息处理时以设备组为单元进行消息转发，提高了消息转发的效率和安全性。
结合第二方面，在第二方面的一种实现方式中，所述分组标记占用所述连接请求消息的固定报头第一个字节中的至少一个比特位。根据本申请实施例的通信方法，通过使分组标记携带在连接请求消息的固定报头中能够与传统的MOTT协议兼容。
结合第二方面及其上述实现方式，在第二方面的另一种实现方式中，所述方法还包括：
接收所述MQTT服务器发送的发布消息，所述发布消息包括所述设备组标识。
根据本申请实施例的通信的方法，通过使MQTT客户端接收的发布消息包括设备组标识，客户端能够得知发布消息的客户端所属的设备组，提高了消息发布的安全性。
第三方面，提供了一种通信装置，该装置可以用来执行第一方面及第一方面的任意可能的实现方式中的第一通信设备的操作。具体地，通信装置包括用于执行上述第一方面所描述的步骤或功能相对应的部件(means)可以是第一方面的第一通信设备。所述步骤或功能可以通过软件实现，或硬件实现，或者通过硬件和软件结合来实现。
第四方面，提供了一种通信装置，该装置可以用来用于执行第二方面及第二方面的任意可能的实现方式中的第二通信设备的操作。具体地，该装置可以包括用于执行上述第二方面所描述的步骤或功能相对应的部件(means)。所述步骤或功能可以通过软件实现，或硬件实现，或者通过硬件和软件结合来实现。
第五方面，提供了一种通信设备，包括，处理器，存储器，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得该通信装置执行第一或第二方面中任一种可能实现方式中的通信方法。
可选地，所述处理器为一个或多个，所述存储器为一个或多个。
可选地，所述存储器可以与所述处理器集成在一起，或者所述存储器与处理器分离设置。
可选的，该通信设备还包括，发射机(发射器)和接收机(接收器)。
一个可能的设计中，提供了一种通信设备，包括收发器、处理器和存储器。该处理器用于控制收发器收发信号，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得该通信设备执行第一方面或第一方面任一种可能实现方式中的方法。
另一个可能的设计中，提供了一种通信设备，包括收发器、处理器和存储器。该处理器用于控制收发器收发信号，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得该通信设备执行第二方面或第二方面任一种可能实现方式中的方法。
第六方面，提供了一种***，所述***包括上述通信装置。
第七方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序(也可以称为代码，或指令)，当所述计算机程序被运行时，使得计算机执行上述第一方面或第二方面中任一种可能实现方式中的方法。
第八方面，提供了一种计算机可读介质，所述计算机可读介质存储有计算机程序(也可以称为代码，或指令)当其在计算机上运行时，使得计算机执行上述第一方面或第二方面中任一种可能实现方式中的方法。
第九方面，提供了一种芯片***，包括存储器和处理器，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得安装有该芯片***的通信设备执行上述第一方面或第二方面中任一种可能实现方式中的方法。
本发明实施例的通信方法、通信装置和通信设备，通过首先对与所述MQTT服务器相连接的客户端分组，再将第一客户端发送的数据，在第一客户端所属的第一设备组内将数据进行转发，或者，接收第二客户端的订阅请求，在第二客户端所属的第一设备组内获取与订阅主题相关的数据，将数据发送给第二客户端，能够提高数据转发的效率以及安全性。
附图说明
图1是本申请的一种应用场景图；
图2是一种聚合消息处理模式示意图；
图3是本申请中一实施例提供的通信方法的示意性框图；
图4是本申请设备组的划分流程示意图；
图5是MQTT主题订阅树的示意图；
图6是以设备组身份标识号作为根的订阅树的示意图；
图7是本申请中所述MQTT服务器内部结构示意图；
图8是本申请分组流程交互示意图；
图9是本申请分组订阅流程交互示意图；
图10是本申请分组发布流程交互示意图；
图11是本申请实施例提供的一种通信装置的结构示意图；
图12是本申请实施例提供的另一种通信装置的结构示意图。
具体实施方式
下面先对MQTT协议中的概念做简单的介绍。
MQTT协议中订阅者即为消息消费者，发布者则是消息生成者，订阅者和发布者之间通过访问控制列表(access control list，ACL)、主题名(topic name，TN)简称为主题(topic)以及主题过滤器(topic filter，TF)来建立“联系”，对MQTT协议来说，不管是消息生成者，还是消息消费者，都统称为客户端。
MQTT消息订阅与发布基于主题名和主题过滤器实现，因此主题在MQTT中是订阅双方的桥梁，十分重要，关于主题名和主题过滤器的概念如下：
主题名：消息发布的主题，是“明确”的主题，不能使用通配符。
主题过滤器：消息订阅的主题，可以包含特殊的通配符，允许你一次订阅多个主题。
MQTT中有一个主题层级的概念，主题是一个结构化、多层的结构，每一层称为主题层级(topic level)，主题层级之间使用主题层级分隔符(‘/’)连接起来，例如：
myhome/groundfloor/livingroom/temperature
客户端可以根据上述主题层级发布消息也可以根据上述主题过滤器订阅相应的主题内容。
主题过滤器通过匹配主题名完成消息订阅，当主题过滤器包含通配符时，主题的分层结构能够实现主题的分层订阅，即订阅某一主题层级下的所有主题消息，MQTT提供了两种通配符机制，如下:
多层通配符(multi-level wildcard)：数字标志(‘#’)是用于匹配主题中任意层级的通配符。多层通配符表示它的父级和任意数量的子层级。多层通配符位于它自己的层级或者跟在主题层级分隔符后面。不管哪种情况，它都是主题过滤器的最后一个字符。
多层通配符匹配示例如下：
myhome/groundfloor/#
各个示例主题及其匹配结果如下：
myhome/groundfloor/livingroom/temperature
myhome/groundfloor/kitchen/temperature
myhome/groundfloor/kitchen/brightness
单层通配符(single-level wildcard)：加号(‘+’)是只能用于单个主题层级匹配的通配符。在主题过滤器的任意层级都可以使用单层通配符，包括第一个和最后一个层级。然而它占据过滤器的整个层级。可以在主题过滤器中的多个层级中使用它，也可以和多层通配符一起使用。
单层通配符匹配示例如下：
myhome/groundfloor/+/temperature
示例主题匹配结构如下：
myhome/groundfloor/livingroom/temperature
myhome/groundfloor/kitchen/temperature
为了便于维护订阅者与发布者的关系，MQTT提供了两种订阅模式：
精确订阅：仅订阅某个客户端(终端)产生的消息。例如，个人通过手机App订阅家庭内的传感器消息。该场景下主题过滤器等同于主题名，即上述的主题名和主题过滤器一致。
模糊订阅：订阅所有终端(通过ACL控制权限)产生的消息。例如，物联网应用(电力供应商)订阅所有用户的设备消息。模糊订阅的订阅者主题过滤器中包括上述的通配符的一种或两种。
下面将结合附图，对本申请中的技术方案进行描述。
图1是本申请的一种应用场景图，该场景包括客户端110，物联网网关120，MQTT服务器130，云服务140和对象150，下面对这五个部分进行详细地介绍。
客户端110(如图1所示包括客户端110a-客户端110f)是使用MQTT协议的客户端，包括使用MQTT协议的程序或设备，其中，使用MQTT协议的程序可以是在任意设备上运行的代码。客户端110通过网络连接到MQTT服务器130，负责采集数据并发布到所述MQTT服务器130。根据应用场景的不同有些客户端可以直接通过MQTT协议连接MQTT服务器，有些客户端需要通过网关连接MQTT服务器。
本申请中，对客户端110具体为哪些设备不做限制，以家里的家电为例，可以是照明***、温度控制***、水流控制***等，也可以是用户所使用的手机、移动电脑或个人电脑等。
客户端110的功能包括：
发布应用消息给其他相关的客户端，例如，家电将相关信息上传；
订阅以请求相关的应用消息，例如，用户通过手机查看家里相关信息；
取消订阅以移除接受应用消息的请求；
从MQTT服务器断开连接。
物联网网关120(如图1所示包括物联网网关120a和物联网网关120b)，充当传感器的接入网关，在MQTT协议中，网关(gateway)可以是一个桥(bridge)模式的MQTT服务器(MQTT server)，当客户端可以直接与MQTT服务器130相连接时，物联网网关也可以是一种客户端。
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内部可以分为多个模块。
MQTT服务器130的功能包括：
接受来自客户端的网络连接；
接受客户端发布的应用消息；
处理客户端的订阅和取消订阅请求；
转发应用消息给符合条件的客户端订阅。
云服务140，用于处理所述MQTT服务器130对客户端110产生的消息进行汇聚、统计等计算处理后的消息，例如将处理后的消息发送给第三方，其中，第三方包括其他应用(application，APP)或者用户或者其他页面，本申请对此并不限制。
对象150(如图1所示包括对象150a和对象150b)，用于接收云服务140发送的数据，可以是网络设备或者应用端。本申请对云服务140处理和处理后数据的发送的对象150不做限制。
现有的基于图1所示的MQTT协议的***架构下，MQTT服务器的主要功能是处理客户端产生的消息，进行汇聚、统计等计算处理后呈现给用户或者第三方应用，把处理结果作为输入进入下一步的处理流程，这种扇入(fan in)的消息处理方式构成了一种聚合的消息处理模式。
图2是一种聚合消息处理模式示意图，该示意图包括发布客户端210，MQTT服务器220，订阅客户端230，下面对这三个部分进行详细地介绍。
发布客户端210(如图2所示包括发布客户端210a-发布客户端210c)，用于向MQTT服务器220发布消息。
MQTT服务器220，用于处理发布客户端210发布的消息，例如，进行汇聚、统计等计算处理。
订阅客户端230，用于从MQTT服务器订阅消息，其中，订阅客户端发送的订阅请求消息中的主题过滤器可以包含通配符(单层通配符或多层通配符)，用于订阅某一类发布客户端210所发布的消息。
基于此模式下的订阅方式，所有客户端消息通过topic匹配无差别推送，这种订阅发布机制虽然实现多对一的消息发布/订阅机制，但是由于没有客户端分组机制，所有的设备均可以无差别订阅与发布消息，这样就会相对的降低了消息通信的安全性，同时通过topic进行消息推送，需要维护一个topic树，对于不同的设备，不同含义的消息需要对topic进行严格区分，这样当物联网中存在设备海量时，topic树的规模也会相对的变得很大，降低消息转发性能。
随着物联网技术的发展，在物联网中存在的设备越来越多，继续采用图2所示的消息处理方式无法满足消息处理的性能要求，例如，消息通信的安全性以及消息处理的效率等。因此本申请提出一种通信方法能够在物联网中设备海量时仍然能够满足消息处理的性能要求。
图3是本申请中一实施例提供的通信的方法的示意性框图。包括S100-S300三个步骤，下面分别对这三个步骤进行详细的描述。
S100，MQTT服务器对客户端分组。
所述MQTT服务器对多个客户端分组，得到至少两个设备组，所述至少两个设备组的每个设备组中包括至少两个客户端。
可选地，客户端向所述MQTT服务器发送连接请求时，发送能够表示所述客户端是否支持分组机制的分组标记，所述MQTT服务器根据分组标记判断发送连接请求的客户端是否支持分组。本申请中，分组标记可以是携带在连接请求的保留位中，也可以是另外发送给所述MQTT服务器的，本申请对此不做限制。此外，每个客户端的分组标记还可以是所述MQTT服务器通过网络规划获知的，此时，客户端不需要发送该分组标记。
客户端向所述MQTT服务器发送连接请求时，发送能够表示所述客户端身份的身份标识，可选地，本申请中所述MQTT服务器可以接收所述多个客户端中每个客户端发送的所述客户端的标识信息，所述客户端的标识信息用于指示所述客户端的身份标识。当客户端支持分组时，所述MQTT服务器根据每个客户端的身份标识将客户端划分为不同的设备组，不同的设备组中的客户端满足不同的分组条件，分组条件由预设的分组规则规定，其中，分组规则是所述MQTT服务器已知的，例如，可以是管理员下发的也可是 网络规划的时候设定好的，本申请对此并不限定。
可选地，上述标识信息可以是客户端的用户的用户名称(user name)、客户端的用户的用户身份标识号(Identity，ID)或者客户端的互联网协议(Internet Protocol，IP)地址，这些标识信息都可以用来唯一确定客户端的身份，本申请对此并不限定，上述身份标识也可以是其他能够表示客户端的身份的信息。
可选地，所述MQTT服务器根据预设的分组规则将连接的客户端分组，得到至少两个设备组，所述至少两个设备组的每个设备组中包括至少两个客户端。
可选地，所述MQTT服务器将每个设备组的ID作为各自设备组中订阅树的根节点，生成订阅树，基于每一个设备组中的订阅树去维护对应设备组中订阅关系，以提高维护效率。
可选地，所述MQTT服务器将每个设备组的ID发送给属于该设备组的每个客户端，例如，携带在连接确认消息中让每个客户端可以在发送消息时指定所属的设备组，所述MQTT服务器也可以不发送设备组的ID，在接收到客户端的消息时通过与客户端之间的连接判断客户端所属的设备组，本申请对此不做限制。
S200，所述MQTT服务器接收客户端发送的发布/订阅请求消息。
可选地，所述MQTT服务器接收客户端发送的发布请求，所述发布请求用于请求所述MQTT服务器发布所述发布请求中的数据，或者，所述MQTT服务器接收客户端发送的订阅请求，所述订阅请求携带有订阅主题的指示信息，所述订阅请求用于请求所述MQTT服务器向所述客户端发送与所述订阅主题对应的数据。
S300，所述MQTT服务器处理发布/订阅请求消息。
可选地，所述MQTT服务器在接收客户端发送的发布请求后，根据S100中的分组，确定发送发布请求的客户端所在的设备组，仅向所述发送发布请求的客户端所在的设备组中订阅了上述数据的订阅客户端发送发布消息，其中，发布消息包括所述发布请求中的数据，可选地，发布消息还可以包括上述设备组的标识，或者，所述MQTT服务器在接收客户端发送的订阅请求后根据S100中的分组，确定发送订阅请求的客户端所在的设备组，在所述发送订阅请求的客户端所在的设备组中匹配与订阅请求中携带主题相对应的数据，并将上述与主题相对应的数据发送给所述订阅客户端，可选地，MQTT服务器还可以将上述设备组的标识信息发送给所述订阅客户端。
为了方便本申请以下具体实施例的描述，首先对本申请实施例中涉及到的报文类型和报文的内容进行一个***的介绍。
首先介绍本申请中与客户端身份标识和分组标记相关的连接报文(client request to connect to server，CONNECT)，CONNECT是由客户端向服务端发送的请求连接消息，包括固定报头、可变报头以及有效载荷三个部分，下面对传统的MQTT协议中CONNECT报文进行介绍。
1、固定报头。
CONNECT报文的固定报头构成，如表1所示：
表1 CONNECT固定报头
Figure PCTCN2019070838-appb-000001
第一字节的高四位为0001低四位为保留位，传统的MQTT协议中CONNECT报文的固定报头第一字节的低四位默认为0，即任意一位保留位均可以使用。
高四位为0001表示消息的类型为CONNECT。传统的MQTT协议中固定报头的第一字节用于表示消息类型和保留字段，消息类型由高四位表示，可以代表16种消息类型， 如表2所示：
表2消息类型
消息类型 高四位十进制值列举 消息描述
保留 0 保留
请求连接 1 客户端请求与服务器连接
连接确定 2 服务器向客户端发送的连接响应
发布 3 客户端向服务器发送的发布消息
发布响应 4 服务器向客户端发送的发布响应
发布接收 5 发布已接收，保证传递1
发布释放 6 发布释放，保证传递2
发布完成 7 发布完成，保证传递3
订阅 8 客户端向服务器发送的订阅请求
订阅应答 9 服务器向客户端发送的订阅应答
取消订阅 10 客户端取消订阅
取消订阅应答 11 服务器取消订阅应答
备份请求 12 客户端备份请求
备份应答 13 服务器备份应答
断开连接 14 服务器断开连接
保留 15 保留
2、可变报头。
CONNECT的可变报头分为四个部分：协议名(protocol name)、协议等级(protocol level)、连接标记(connect flags)、保持连接(keep alive)。不同版本的MQTT协议存在不同的协议名和协议等级。如果MQTT服务器发现协议名不正确的话，就断开连接。如果是协议等级不对应，返回一个码告知客户端。
连接标记里面包括用户名标记(user name flag)、密码标记(password flag)、遗嘱保留(will retain)、清理会话(clean session)、保留(reserved)等。它们的位置如表3所示：
表3 CONNECT连接标记
Figure PCTCN2019070838-appb-000002
本申请中当身份标识为上述的客户端的用户的用户身份标识号(Identity，ID)时，与表3可变报头的连接标记部分中的用户名标记(user name flag)相关。
用户名标记(user name flag)：
user name flag用于标示在有效载荷里有没有相关的部分。比如。当就用户名标示为1的时候，那就是说明有效载荷部分里面有用户名的信息。
3、有效载荷。
CONNECT消息的有效载荷根据可变头部中各标记位的置位情况，包含一个或多个UTF-8编码字符串。本申请中介绍有效载荷中的客户端的用户的用户身份标识号和用户名字符串。
客户端的用户的用户ID：
这是第1个UTF编码字符串。客户端的用户的用户ID(Client ID)的长度为1至23个字符，服务器根据客户端的用户的用户ID可以指定到唯一的客户端，因此，本申请中MQTT server可以根据用户ID确定客户端身份，并以此对客户端分组。对于连接 到某个MQTT server的所有客户端，它们的用户ID都是唯一的。
用户名：
如果在表3中用户名标记被置位，则用户名将是有效载荷中的一个字符串。用户名字段用于认证，标明了连接的用户的名字，本申请中MQTT server也可以根据客户端用户的用户名确定客户端身份，并以此对客户端分组。
其次介绍本申请中与向客户端发送设备组ID相关的连接确定报文(CONNACK)，CONNACK是由所述MQTT服务器向客户端发送的响应请求连接的连接响应消息，包括固定报头、可变报头两个部分，下面对传统的MQTT协议中CONNACK报文进行介绍。
1、固定报头。
CONNACK报文的固定报头构成，如表4所示：
表4 CONNACK固定报头
Figure PCTCN2019070838-appb-000003
第一字节的高四位为0010低四位为保留位，传统的MQTT协议中CONNACK报文的固定报头第一字节低四位与CONNECT报文的固定报头的第一字节低四位值相同。本申请中，当客户端支持分组机制，并在CONNECT报文的固定报头的第一字节低四位中携带有分组标志，则CONNACK报文的固定报头第一字节低四位需要同步发生变化。
第一字节的高四位为0010表示消息的类型为CONNACK。
2、可变报头。
CONNACK可变报头的构成，如表5所示：
表5 CONNACK可变报头
Figure PCTCN2019070838-appb-000004
本申请以分组标记携带在CONNECT的固定报头中为例，说明如何判断客户端是否支持分组机制，从表1中可以看出CONNECT的固定报头中低四位为保留位，传统的MQTT协议中低四位默认为0，即任意一位空余位置均可以使用，例如：
可选地，本申请中可以用第0个比特位作为分组标记，例如，第0个比特位的值为1时表示客户端支持设备组机制，第0个比特位的值为1时表示客户端不支持设备组机制，不支持设备组机制的客户端支持MQTT原有的消息订阅和发布机制，可以是精确订阅或者模糊订阅。
可选地，本申请中也可以用第1个比特位作为分组标记，如上所述第1个比特位的值为1时表示客户端支持设备组机制。
可选地，本申请中也可以用第2个比特位作为分组标记，如上所述第2个比特位的值为1时表示客户端支持设备组机制。
可选地，本申请中也可以用第3个比特位作为分组标记，如上所述第3个比特位的值为1时表示客户端支持设备组机制。
可选地，本申请中也可以用第0和1个比特位作为分组标记，如上所述第0和1个比特位的值均为1时表示客户端支持设备组机制。
可选地，本申请中也可以用第0和2个比特位作为分组标记，如上所述第0和2个比特位的值均为1时表示客户端支持设备组机制。
还有其他用低四位的值表示客户端支持设备组机制的形式，这里不进行一一列举，只要是低四位值中有至少一位与传统的MQTT协议中低四位默认值不同，即可表示客户端支持设备组机制。
应理解，使用传统的MQTT协议CONNECT的固定报头中保留位中至少一位作为分组标记位，只是本申请的一个实施例，本申请中使用保留位可以与传统的MQTT协议兼容并且节省了信息开销，但是其他指示分组标记的信息也在本申请的保护范围之内。
可选地，服务器可以将设备组的设备组标识发送给客户端，例如，本申请以服务器向客户端发送的设备组标识携带在CONNACK报文的可变报头中为例，说明如何通知客户端所属的设备组。服务器发送CONNACK报文以响应从客户端收到的CONNECT报文。服务器发送给客户端的第一个报文是CONNACK，如果客户端在合理的时间内没有收到服务器的CONNACK报文，客户端应该关闭网络连接。合理的时间取决于应用的类型和通信基础设施。从表5中可以看出CONNACK的可变报头中第二字节为连接返回码，本申请中，客户端支持分组机制时，CONNACK的固定报头第一字节的低四位保留位的值会同步CONNECT的固定报头第一字节的低四位的值，CONNACK可变报头可以在连接返回码后面带上发送CONNECT的客户端的设备组标识，本申请中CONNACK可变报头的保留位是不加修改的。
应理解，使用传统的MQTT协议CONNACK的可变报头在连接返回码后面带上发送CONNECT的客户端所属的设备组的设备组标识，只是本申请的一个实施例，本申请中使用连接返回码可以与传统的MQTT协议兼容并且节省了信息开销，但是其他携带客户端所属的设备组的设备组标识的信息也在本申请的保护范围之内。
图4是本申请设备组的划分流程示意图。在本申请实施案例中，采用客户端的用户名称作为身份标识，基于user name进行客户端的分组划分，客户端与服务器建立连接时，服务器需要通过客户端鉴权机制保证客户端的合法性，基于user name下发分组规则，在一定程度上保证只有合法的客户端才能参与设备组的划分，具体划分流程如图4所示，包括S110-S150以及S131六个步骤，下面对这六个步骤进行详细的描述。
S110，客户端向服务器发送连接请求消息。
客户端向服务端设备发送CONNECT消息，其中，CONNECT报文的固定报头中携带有分组标记，其中分组标记用于判断客户端是否支持设备组机制，CONNECT报文的有效载荷部分携带有身份标识，其中身份标识用于唯一指定客户端的身份，例如，身份标识可以是user name，CONNECT报文的有效载荷跟CONNECT报文的可变报头的一些标记相关。
可选地，本实施例以发送CONNECT报文的固定报头格式如表6所示为例：
表6 CONNECT固定报头
Figure PCTCN2019070838-appb-000005
由上文中描述的本申请中可以作为分组标记的可能可知，低四位中有至少一位与传统MQTT协议中的CONNECT报文的固定报头低四位默认值不一致时，认为发送CONNECT的客户端支持设备组机制，即，服务器可以对其分组。
可选地，本实施例以发送CONNECT报文的可变报头中用户名标记位置1为例，即，CONNECT报文的有效载荷用户名部分是有效载荷中的一个字符串，用户名字段用于标明连接的客户端的用户的名字。
可选地，本实施例以user name作为身份标识，能够在本申请对客户端逻辑设备组分离的基础上进一步增强MQTT消息分发的安全性，因为控制访问列表可以基于客户端的user name进行鉴权操作保证客户端的合法性。
S120，服务器对客户端鉴权。
客户端与服务器建立连接时，需要通过客户端鉴权机制保证客户端的合法性，本实施例基于user name下发设备组划分规则，在一定程度上保证只有合法的客户端才能参与设备组的划分。
S130，服务器检查客户端是否支持分组。
服务器接收到客户端发送的CONNECT连接请求消息之后，本实施例中服务器根据CONNECT报文的固定报头中低四位的值。可得到发送CONNECT连接请求消息的客户端是否支持分组机制。
以上述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等。
可选地，本实施例中当上述CONNECT报文的固定报头格式与传统的MQTT协议的CONNECT报文的固定报头格式一致时，则可得到发送CONNECT的客户端不支持分组机制。当不支持分组机制时，默认客户端为公共组，其发布的消息能够被所有订阅客户端订阅。
S131，生成MQTT主题订阅树。
可选地，本实施例中当客户端不支持分组机制时，即，服务器无法对客户端分组，则对于客户端后续的消息发布以及消息订阅采用现有的发布或者订阅机制。如图5所示，其中，T1、T2…..等为主题名称，图5是现有的生成MQTT主题订阅树的示意图，所有的订阅关系都是通过一颗订阅树来维护，在订阅树中，topic将被按照“/”组织成树状结构，如图5所示的订阅树，其中订阅树的每个节点都是一个topic分级，每个节点对应的topic就是从根节点到当前节点所组成的topic。
S140，服务器指定客户端所属的设备组的设备组标识。
可选地，本实施例中当客户端支持分组机制时，服务器根据预先设定的分组机制对客户端分组，并指定客户端所在设备组的设备组标识，本实施例中，可选地，例如客户端的user name为A1则根据上述分组规则，客户端指定该客户端所属设备组的设备组标识为ID1。
S150，服务器以设备组标识作为订阅树的根。
可选地，本实施例中以设备组ID作为订阅树的根，维护所述设备组内的订阅关系。如图6所示，T2、T21…..等为主题名称，图6是以设备组ID作为根节点的订阅树的示意图，则在不同的设备组中可以有相同主题的消息发布，因为不同组间相互独立的，增强了消息发布的灵活性，并且在各个小组中进行消息的发布或者订阅，降低了主题树的检索规模，提高了消息推送效率。
本申请中，支持分组机制的客户端根据user name分组并以每个设备组的设备组ID作为订阅树的根后，划分设备组流程结束；不支持分组机制的客户端根据现有的以主题名称作为订阅树的根节点，划分流程结束。
当连接建立成功以后，基于同一设备组ID的客户端构成一个隔离的物联网络，服务器对在同一个物联网络内的客户端进行消息订阅和消息推送，并允许客户端在消息发送时指定设备组ID，可以进行设备组间的消息推送。
应理解，本申请中该实施例以CONNECT报文的固定报头低四位的第0比特位作为分组标记以及以客户端user name作为身份标识。只是为了说明划分流程而列举出的参数实例，其他的可以作为分组标记以及身份标识的信息，例如，客户端向服务器发送的其 他信息携带有分组标记以及身份标识也在本申请的保护范围之内。
图7是本申请中MQTT服务器内部结构示意图，包括访问控制列表310，持久服务模块320，会话管理模块330，订阅服务模块340，发布服务模块350，数据包管理模块360，数据包引擎370，其中，与现有MQTT服务器不同的是本申请中MQTT服务器增加了数据包引擎360和数据包引擎370，用于实现对客户端分组的功能。
下面对这七个部分进行详细地介绍。
访问控制列表(access control list，ACL)310，用于负责客户端接入认证与操作鉴权，客户端连接时提供用户名密码或证书，ACL模块对客户端进行认证，认证通过后把客户端的会话(session)保存在会话管理(session manager)模块中。
客户端操作时，ACL对操作执行鉴权，主要包含发布、订阅这两个操作，ACL需要校验客户端对发布、订阅的主题(topic)是否有访问(读、写)的权限，如果没有权限则拒绝该操作，否则转到对应的服务模块执行操作处理。
持久服务模块(persistent service)320，用于负责消息、session、客户端等信息的持久化。
会话管理模块(session manager)330，用于负责客户端session的管理，当客户端断连后重连时，只要session在有效期内，session manager可以根据其session恢复其订阅，并重新下发断连期间新的消息。
订阅服务模块(subscribe service)340，用于处理消息订阅请求的服务部件，当客户端提交订阅请求时，依照MQTT的订阅处理逻辑进行处理：遍历该订阅过滤器中的主题层级，挂到订阅树对应的节点上。最后把该订阅客户端挂到最后一层主题层级对应节点的客户端列表中。
发布服务模块(publish service)350，用于处理消息发布的服务部件，当客户端发布消息时，ACL鉴权通过后，发布服务模块进行发布消息的转发。该部件包含三个功能：
根据发布消息的QoS、保留(retain)标识及订阅情况进行处理包括以下几种情况：
如果是retain消息，需要调用persistent service把消息持久化；
如果是QoS>0的消息，除了做一遍QoS＝0的操作之外，还需要把消息保存一段时间，在订阅客户端临时断连后重新连接时再做一次订阅恢复及派发。
发布服务模块中还包括主题匹配模块(topic matcher)用于处理遍历订阅树，把发布主题与订阅过滤器进行匹配，把消息派发给匹配成功的订阅客户端。
发布服务模块中还包括标签匹配模块(tags matcher)用于处理发布、订阅客户端的标签，标签的匹配处理包括：
在topic matcher匹配结束后，得到匹配成功的主题过滤器及其对应的客户端列表；
遍历这些客户端列表，如果客户端订阅时设定支持标签意识(tag-aware)，则调用标签引擎(tags engine)执行，匹配成功把消息派发给该客户端；否则，默认订阅方式是不支持tag-aware，则不需要处理，直接把消息派发给该客户端。
数据包管理模块(packet manager)360作为session manager的补充，提供了客户端数据包(packet)属性的管理服务，在本申请中，数据包管理模块用于维护分组信息，例如，当前有哪些设备组分别对应哪些分组规则，图4中所述的，规定user name为A1、A2、A3的客户端为一个设备组，所属设备组的设备组标识为身份标识码(Identity，ID)规定为ID1，规定user name为B1、B2、B3的客户端为一个设备组，所属设备组的ID为ID2，所述A1属于ID1的分组信息可以由数据包管理模块管理。
数据包引擎(packet engine)370，用于执行packet分组的规则引擎，根据packet分组规则，对连接的客户端分组划分，匹配分组，检索分组订阅树，本申请中的数据包引擎是分组动作的执行，根据制定规则执行分组动作，例如，数据包管理模块获取了分 组规则规定A1属于ID1的信息，数据包引擎可以根据分组信息将A1划分到ID1。
应理解，图7是服务器内部具体结构示意图，可以是一个程序包含的多个功能模块，各个模块在程序内部有相同或不同的进程、线程负责执行，所以对于本申请来说服务器执行发布/订阅消息的处理，可以是执行一个或多个程序，本申请对此并不限定。本申请中的服务器也可以仅仅包括发布/订阅服务模块和数据包管理模块以及数据包引擎，仅完成分组发布/订阅，可以不对客户端鉴权，也可以不包括持久服务模块和会话管理模块，本申请中对ACL310、persistent service320以及session manager330不做详细的介绍，下面重点介绍本申请中在分组机制的下，服务器的发布/订阅服务模块和数据包管理模块以及数据包引擎是如何完成对客户端分组，并在设备组内进行消息处理的。
应理解，图7是服务器内部具体结构示意图，包括简单的服务器内部执行功能模块，对于与客户端之间的消息交互，可以是现有技术中的通信模块完成，例如，通信模块可以用于接收或发送消息，这里介绍服务器内部具体结构时不涉及。
图8是本申请分组流程交互示意图。包括S210-S230以及S221-S222五个步骤，下面对这五个步骤进行详细的描述。
S210，客户端向服务器发送连接请求消息。
客户端向服务器发送连接请求消息CONNECT，其中，CONNECT携带有分组标记，服务器可以根据分组标记判断客户端是否支持分组。
S220，服务器检查客户端是否支持设备组机制。
服务器的MQTT服务器数据包管理模块根据CONNECT中的分组标记检查客户端是否支持分组。
S221，服务器与客户端建立连接。
客户端不支持分组机制时，服务器根据CONNECT与客户端建立连接，并进行接下来的消息发布和消息订阅。
S222，服务器确定客户端支持分组。
客户端支持分组机制时，服务器的数据包引擎单元按照分组规则对客户端分组。
S230，服务器与客户端建立连接。
支持分组机制的客户端在分组之后与服务器建立连接。
本申请中的MQTT服务器与客户端在建立连接时，会根据客户端在连接请求消息中携带的分组标记确认客户端是否支持分组机制，在客户端支持分组机制时对客户端分组，能够在后续基于设备组进行消息发布/订阅提高了消息处理的效率和安全性。
图9是本申请分组订阅流程交互示意图。本实施例中客户端在成功发送CONNECT消息，并得到服务器端授权允许建立彼此连接的CONNACK消息之后，客户端发送订阅请求消息(subscribe message)，订阅感兴趣的topic主题列表(至少一个主题)。
图9包括S310-S350五个步骤，下面对这五个步骤进行详细的描述。
S310，订阅客户端向服务器发送订阅请求消息。
消息订阅客户端向服务器的订阅服务模块(subscribe service)发送订阅请求消息(subscribe message)，其中，subscribe message包含包标识符和订阅列表，包标识符是客户端和服务器之间的唯一标识符，用于标识消息流中的某个消息。订阅消息可以包含对某个客户端的任意数量消息的订阅，每个订阅都是由一对主题和QoS级别组成。订阅消息的主题还可以包含通配符，这使得订阅客户端可以订阅特定的主题模式。如果对一个客户端有重叠订阅，则代理服务器将使用该主题的最高QoS级别传递消息。
本申请中，对订阅消息的包标识符和订阅列表不做限制，可以为任意一种订阅消息。
S320，服务器检查客户端的分组情况。
服务器的数据包管理器(packet manager)对客户端的数据包属性进行管理服务， 检查订阅客户端的分组情况。
本申请中，客户端向服务器发起连接请求时，即，发送CONNECT时，会携带身份标识和分组标记，服务器根据分组标记会判断客户端是否支持分组，根据身份标识将客户端指定在一个设备组内。
本申请中，当客户端订阅消息时，服务器会根据建立连接时的消息再次判断发送订阅消息的客户端是否支持分组，以及所属的设备组。
S330，服务器确定客户端所属的设备组。
服务器的数据包引擎(packet engine)执行客户端的数据包分组，根据分组规则分组。
本申请中，客户端向服务器发送订阅消息时，例如客户端支持分组则数据包引擎会为客户端匹配分组信息，将客户端划分到对应的设备组。
S340，客户端分组订阅。
本申请中，客户端被划分到所属的设备组后，会在所属设备组内订阅消息，服务器以设备组ID为根目录生成订阅树。
S350，客户端订阅成功。
服务器的订阅服务模块根据以设备组ID为根目录的订阅树，遍历该客户端订阅过滤器中的主题层级，挂到订阅树对应的节点上。最后把该订阅客户端挂到最后一层主题层级对应节点的客户端列表中，完成订阅过程。服务器会向订阅客户端发送订阅应答(SUBACK)消息。
本实施例中，给出的是支持分组的客户端订阅流程，若是不支持分组的客户端订阅消息，直接是服务器的订阅服务模块响应，不会经过数据包管理器和数据包引擎分组。
图10是本申请分组发布流程交互示意图。包括S410-S450五个步骤，下面对这五个步骤进行详细的描述。
本申请中在MQTT进行消息发布时，需要根据分组结果发布，传统的MQTT协议的发布(PUBLISH)报文第一字节的第一比特位与第二比特位均为1时为保留位，本申请中可以将所述保留位作为设备组标识位，若保留位为真，即，上述第一比特位与第二比特位均为1，则消息发布可以在PUBLISH报文的可变报头中指定设备组ID。PUBLISH报文的固定报头格式，如表7所示：
表7 PUBLISH固定报头
Figure PCTCN2019070838-appb-000006
S410，发布客户端向服务器发送发布请求消息。
消息发布客户端向服务器发送发布请求消息(publish message)，其中，publish message携带有主题信息。
S420，服务器检查发布客户端分组情况。
服务器中的数据包管理器(packet manager)对客户端的数据包属性进行检查，判断发布客户端分组情况。
本申请中，客户端向服务器发起连接请求时，即，发送CONNECT时，会携带身份标识和分组标记，客户端根据分组标记会判断客户端是否支持分组，根据身份标识将客户端指定在一个设备组内。
本申请中，当客户端发布消息时，服务器会根据建立连接时的消息再次判断发送发布消息的客户端是否支持分组，以及所属的设备组,可选地，发布客户端向服务器发送的PUBLISH报文的可变报头中指定设备组ID时，服务器可以根据发布客户端指定的设 备组ID获取发布客户端所属设备组信息。
S430，服务器检查发布客户端对应的订阅树。
服务器中的数据包引擎(packet engine)执行客户端的数据包分组，根据分组规则分组划分，匹配分组，并检查发布客户端对应设备组的订阅树。
本申请中，客户端向服务器发送发布消息时，例如客户端支持分组则数据包引擎会为客户端匹配分组信息，将客户端划分到对应的设备组，并检查对应设备组的订阅树。
S440，服务器根据发布消息进行主题匹配。
服务器中的主题匹配器根据发布客户端发送的发布消息，在发布客户端所属的设备组中进行主题匹配。
本申请中，服务器在对客户端分组之后，将发布的消息在所述的设备组中推送，判断同一个设备组中有没有客户端订阅响应主题消息，进行主题匹配，将消息推送出去。
S450，服务器将发布消息转发给对应的订阅客户端。
服务器连接发布客户端与订阅客户端，将订阅客户端订阅的相匹配的主题消息从发布客户端接收过来，并转发给同一个设备组中与订阅了对应的发布主题的订阅客户端。
本实施例中，给出的是支持分组的客户端发布消息流程，若是不支持分组的客户端发布消息，与传统发布流程一样不会经过数据包管理器和数据包引擎分组。
应理解，本实施例中订阅客户端和发布客户端只是举例说明的形式，在MQTT协议中，客户端可以是订阅客户端和/或发布客户端，本申请对此并不限制。
图11是本申请中一种通信装置的结构示意图，包括分组单元410，接收单元420，确定单元430和发送单元440，下面对这四个部分进行详细的介绍。
服务器的分组单元410，其中，可选地，服务器的分组单元410，可以用于对多个客户端分组，得到至少两个设备组，所述至少两个设备组的每个设备组中包括至少两个客户端。分组单元还用于确定分组条件，所述分组条件包括被划分至同一设备组的客户端的身份标识所需要满足的条件，其中，一个身份标识能够唯一地指示一个客户端；根据所述多个客户端的身份标识和所述分组条件，对所述多个客户端。
例如，可以是图7中的数据包管理模块和数据包引擎单元完成的，其中，数据包管理模块用于管理分组信息，不同的设备组所对应的分组规则，确定客户端所属的设备组，而数据包引擎用于执行分组，所以，应理解本申请中分组单元可以是图7中的数据包管理模块和数据包引擎合作完成的，而数据包管理模块和数据包引擎可以是一个模块的两个功能也可以是多个模块，本申请对此并不限制。
服务器的接收单元420，其中，可选地，服务器的接收单元420，可以用于接收第一客户端发送的发布请求，所述发布请求包括第一数据，所述第一数据对应第一主题，所述发布请求用于请求服务器发布所述第一数据。
接收单元420还可以接收第二客户端发送的订阅请求，订阅请求携带有第一主题的指示信息，订阅请求用于请求MQTT服务器向第二客户端发送第一主题对应的数据。
接收单元420还可以接收多个客户端中每个客户端发送的分组标记，每个分组标记用于指示所对应的客户端是否允许被划分至设备组。。
例如，本申请中接收单元420可以是MQTT服务器与客户端相互通信的模块执行的。
服务器的确定单元430，其中，可选地，确定单元430，可以用于从所述至少两个设备组中确定所述第一客户端所属的第一设备组，仅向所述第一设备组内的至少一个第二客户端发送发布消息，其中，发布消息包括上述第一数据，发布消息还可以包括上述第一设备组的设备组标识，或者，确定单元，可以用于从所述至少两个设备组中确定所述第二客户端所属的第一设备组，并确定第一数据，所述第一数据来自所述第一设备组中至少一个客户端，所述第一数据与所述第一主题相对应。例如，确定单元430，可以是图7中的数据包管理模块和数据包引擎单元完成的，其中，数据包管理模块用于管理 分组信息，不同的设备组所对应的分组规则，确定客户端所属的设备组，而数据包引擎用于根据数据包管理模块管理的分组规则确定分组。
服务器的发送单元440，其中，可选地，发送单元440，可以用于向上述第二客户端发送所述发布消息。例如，确定单元440，可以是MQTT服务器与客户端相互通信的模块执行的。
可选地，本申请中，上述410-440四个部分可以是服务器一个功能模块具有的四种功能。本申请对此不做限制。
图12是本申请中另一种通信装置的结构示意图，包括发送单元510和接收单元520两个部分，下面对这两个部分进行详细的介绍。
客户端发送单元510，可选地，本申请中客户端发送单元510可以用于向服务器发送连接请求消息、发布消息或订阅消息。
客户端接收单元520，可选地，本申请中客户端接收单元520可以用于接收服务器发送的连接确认消息或发布消息。
可选地，本申请中，上述510-520两个部分可以是客户端一个功能模块具有的两种功能。本申请对此不做限制。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (22)

  1. 一种通信方法，其特征在于，应用于消息队列遥测传输MQTT服务器，所述方法包括：
    对多个客户端分组，得到至少两个设备组，所述至少两个设备组的每个设备组中包括至少两个客户端；
    接收第一客户端发送的发布请求，所述发布请求包括第一数据，所述第一数据对应第一主题，所述发布请求用于请求所述MQTT服务器发布所述第一数据；
    确定所述第一客户端所属的第一设备组，其中，所述第一设备组为所述至少两个设备组中的任一设备组，并向所述第一设备组内的第二客户端发送发布消息，所述发布消息包括所述第一数据。
  2. 根据权利要求1所述的方法，其特征在于，所述接收第一客户端发送的发布请求之前，所述方法还包括：
    接收所述第二客户端发送的订阅请求，所述订阅请求携带有所述第一主题的指示信息，所述订阅请求用于请求所述MQTT服务器向所述第二客户端发送所述第一主题对应的数据。
  3. 根据权利要求1或2所述的方法，其特征在于，所述对多个客户端分组包括：
    确定分组条件，所述分组条件包括被划分至同一设备组的客户端的身份标识所需要满足的条件，其中，一个身份标识能够唯一地指示一个客户端；
    根据所述多个客户端的身份标识和所述分组条件，对所述多个客户端分组。
  4. 根据权利要求3所述的方法，其特征在于，在根据所述多个客户端的身份标识和所述分组条件，对所述多个客户端分组之前，所述方法还包括：
    接收所述多个客户端中每个客户端发送的所述客户端的标识信息，所述客户端的标识信息用于指示所述客户端的身份标识。
  5. 根据权利要求3或4所述的方法，其特征在于，所述确定所述第一客户端所属的第一设备组包括：
    根据所述第一客户端的身份标识和所述分组条件，确定所述第一设备组。
  6. 根据权利要求1至5中任一项所述的方法，其特征在于，在所述对多个客户端分组之前，所述方法还包括：
    确定所述多个客户端中的每个客户端允许被划分至设备组。
  7. 根据权利要求6所述的方法，其特征在于，所述确定所述多个客户端中的每个客户端允许被划分至设备组，包括：
    接收所述多个客户端中每个客户端发送的分组标记，每个分组标记用于指示所对应的客户端是否允许被划分至设备组。
  8. 根据权利要求7所述的方法，其特征在于，所述分组标记承载于连接请求消息，其中，所述连接请求消息用于请求与所述MQTT服务器建立连接。
  9. 一种通信方法，其特征在于，应用于消息队列遥测传输MQTT客户端，所述方法包括：
    向MQTT服务器发送连接请求消息，所述连接请求消息用于请求与所述MQTT服务器建立连接，所述连接请求消息包括分组标记；
    接收所述MQTT服务器发送的连接确认消息，所述连接确认消息用于确认所述MQTT服务器已经和所述MQTT客户端建立连接，所述连接确认消息包括所述MQTT服务器为所 述MQTT客户端分配的设备组标识。
  10. 根据权利要求9所述的方法，其特征在于，所述分组标记占用所述连接请求消息的固定报头第一个字节中的至少一个比特位。
  11. 根据权利要求9或10所述的方法，其特征在于，所述方法还包括：
    接收所述MQTT服务器发送的发布消息，所述发布消息包括所述设备组标识。
  12. 一种通信装置，其特征在于，应用于消息队列遥测传输MQTT服务器，所述装置包括：
    分组单元，用于对多个客户端分组，得到至少两个设备组，所述至少两个设备组的每个设备组中包括至少两个客户端；
    接收单元，用于接收第一客户端发送的发布请求，所述发布请求包括第一数据，所述第一数据对应第一主题，所述发布请求用于请求所述MQTT服务器发布所述第一数据；
    确定单元，用于确定所述第一客户端所属的第一设备组，其中，所述第一设备组为所述至少两个设备组中的任一设备组；
    发送单元，用于向所述第一设备组内的第二客户端发送发布消息，所述发布消息包括所述第一数据。
  13. 根据权利要求12所述的装置，其特征在于，所述接收单元还用于接收所述第二客户端发送的订阅请求，所述订阅请求携带有所述第一主题的指示信息，所述订阅请求用于请求所述MQTT服务器向所述第二客户端发送所述第一主题对应的数据。
  14. 根据权利要求12或13所述的装置，其特征在于，所述分组单元具体用于：
    确定分组条件，所述分组条件包括被划分至同一设备组的客户端的身份标识所需要满足的条件，其中，一个身份标识能够唯一地指示一个客户端；
    根据所述多个客户端的身份标识和所述分组条件，对所述多个客户端分组。
  15. 根据权利要求14所述的装置，其特征在于，所述接收单元还用于在根据所述多个客户端的身份标识和所述分组条件，对所述多个客户端分组之前，接收所述多个客户端中每个客户端发送的所述客户端的标识信息，所述客户端的标识信息用于指示所述客户端的身份标识。
  16. 根据权利要求14或15所述的装置，其特征在于，所述确定单元具体用于根据所述第一客户端的身份标识和所述分组条件，确定所述第一设备组。
  17. 根据权利要求12至16中任一项所述的装置，其特征在于，所述确定单元还用于在所述MQTT服务器对多个客户端分组之前，确定所述多个客户端中的每个客户端允许被划分至设备组。
  18. 根据权利要求17所述的装置，其特征在于，所述确定单元确定所述多个客户端中的每个客户端允许被划分至设备组具体包括：
    所述接收单元接收所述多个客户端中每个客户端发送的分组标记，每个分组标记用于指示所对应的客户端是否允许被划分至设备组。
  19. 根据权利要求18所述的装置，其特征在于，所述分组标记承载于连接请求消息，其中，所述连接请求消息用于请求与所述MQTT服务器建立连接。
  20. 一种通信装置，其特征在于，应用于消息队列遥测传输MQTT客户端，所述装置包括：
    发送单元，用于向所述MQTT服务器发送连接请求消息，所述连接请求消息用于请求与所述MQTT服务器建立连接，所述连接请求消息包括分组标记；
    接收单元，用于接收所述MQTT服务器发送的连接确认消息，所述连接确认消息用于确认所述MQTT服务器已经和所述MQTT客户端建立连接，所述连接确认消息包括所述 MQTT服务器为所述MQTT客户端分配的设备组标识。
  21. 根据权利要求20所述的装置，其特征在于，所述分组标记占用所述连接请求消息的固定报头第一个字节中的至少一个比特位。
  22. 根据权利要求20或21所述的装置，其特征在于，所述接收单元还用于接收所述MQTT服务器发送的发布消息，所述发布消息包括所述设备组标识。
PCT/CN2019/070838 2018-01-16 2019-01-08 通信方法和通信装置 WO2019141111A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP19740907.1A EP3734913A4 (en) 2018-01-16 2019-01-08 COMMUNICATION PROCESS AND COMMUNICATION DEVICE
US16/928,204 US11411897B2 (en) 2018-01-16 2020-07-14 Communication method and communication apparatus for message queue telemetry transport

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810038597.7 2018-01-16
CN201810038597.7A CN110048927B (zh) 2018-01-16 2018-01-16 通信方法和通信装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/928,204 Continuation US11411897B2 (en) 2018-01-16 2020-07-14 Communication method and communication apparatus for message queue telemetry transport

Publications (1)

Publication Number Publication Date
WO2019141111A1 true WO2019141111A1 (zh) 2019-07-25

Family

ID=67273375

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/070838 WO2019141111A1 (zh) 2018-01-16 2019-01-08 通信方法和通信装置

Country Status (4)

Country Link
US (1) US11411897B2 (zh)
EP (1) EP3734913A4 (zh)
CN (1) CN110048927B (zh)
WO (1) WO2019141111A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111371889A (zh) * 2020-03-03 2020-07-03 广州致远电子有限公司 消息处理方法、装置、物联网***和存储介质
CN111416867A (zh) * 2020-03-25 2020-07-14 上海商米科技集团股份有限公司 不同设备间的消息处理方法、服务器和计算机存储介质
CN114979198A (zh) * 2022-04-19 2022-08-30 深圳市爱为物联科技有限公司 一种适用于物联网平台通用数据处理的解决方法

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111221845A (zh) * 2019-12-31 2020-06-02 华为技术有限公司 一种跨设备信息搜索方法及终端设备
CN115462054A (zh) * 2020-05-28 2022-12-09 西门子股份公司 通信转换方法、网关设备、网络***和计算机介质
CN112328417B (zh) * 2020-11-27 2023-12-12 杭州海兴电力科技股份有限公司 一种嵌入式多程序通讯方法和***
US11121930B1 (en) * 2020-12-01 2021-09-14 Cirrus Link Solutions, LLC Sparkplug-aware MQTT server
CN112839087A (zh) * 2021-01-06 2021-05-25 深圳市芯中芯科技有限公司 一种基于集群的多终端控制方法及***
CN112714026A (zh) * 2021-01-21 2021-04-27 广州朗国电子科技有限公司 一种mqtt协议消费者的集群方法、装置及储存介质
CN113014584A (zh) * 2021-02-26 2021-06-22 北京金山云网络技术有限公司 一种物联网通信方法、装置、电子设备及存储介质
CN115412269A (zh) * 2021-05-26 2022-11-29 腾讯云计算（北京）有限责任公司 业务处理方法、装置、服务器及存储介质
CN113918483B (zh) * 2021-12-14 2022-03-01 南京芯驰半导体科技有限公司 一种多主设备缓存控制方法及***
US11882201B2 (en) * 2022-03-30 2024-01-23 Itron, Inc. Data compression techniques for efficient network management
CN115086416B (zh) * 2022-06-14 2024-05-28 杭州安恒信息技术股份有限公司 基于订阅机制的通信***及通信方法
CN115150380A (zh) * 2022-06-30 2022-10-04 广发证券股份有限公司 一种适用于多路行情源的行情订阅及发布方法及装置
CN114866597B (zh) * 2022-07-11 2022-11-11 广东睿江云计算股份有限公司 一种分组管理客户端连接方法以及***
US20240039820A1 (en) * 2022-08-01 2024-02-01 Schneider Electric Systems Usa, Inc. Messaging protocol for configuring remote terminal unit
CN115567584A (zh) * 2022-09-21 2023-01-03 北京百度网讯科技有限公司 订阅主题的处理方法、装置、电子设备及可读存储介质
WO2024064331A1 (en) * 2022-09-23 2024-03-28 Aveva Software, Llc Servers, systems, and methods for automatically transforming a mqtt topic-payload into any format

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102308548A (zh) * 2009-02-12 2012-01-04 国际商业机器公司 在发布和定制引擎中引入加密、认证和授权
WO2017143227A1 (en) * 2016-02-19 2017-08-24 Intel Corporation Internet-of-things device blank
CN107567700A (zh) * 2015-03-10 2018-01-09 英特尔公司 使用基于密钥的加入协议的物联网组形成

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6122483A (en) * 1999-06-28 2000-09-19 Nortel Networks Limited Method and apparatus for multicast messaging in a public satellite network
US7720903B1 (en) * 2000-08-31 2010-05-18 Intel Corporation Client messaging in multicast networks
CN101668031B (zh) * 2008-09-02 2013-10-16 阿里巴巴集团控股有限公司 一种消息处理方法及***
US9300540B2 (en) * 2010-11-09 2016-03-29 Avaya Inc. Multicast network diagnostics
US8725681B1 (en) * 2011-04-23 2014-05-13 Infoblox Inc. Synthesized identifiers for system information database
WO2014023327A1 (en) * 2012-08-06 2014-02-13 Telefonaktiebolaget L M Ericsson (Publ) Dynamic content filtering of data traffic in a communication network
CN102956052A (zh) * 2012-08-14 2013-03-06 姚利龙 一种基于移动智能终端的排队叫号方法及***
US10015293B2 (en) * 2013-02-08 2018-07-03 Iot Holdings, Inc. Method and apparatus for incorporating an internet of things (IoT) service interface protocol layer in a node
US9131353B2 (en) * 2013-05-08 2015-09-08 Intel Corporation Apparatus, system and method of setting up an application service platform (ASP) peer to peer (P2P) group
US9660943B2 (en) * 2014-04-25 2017-05-23 International Business Machines Corporation Messaging based signaling for communications sessions
CN104539587A (zh) * 2014-12-09 2015-04-22 中国电子科技集团公司第十五研究所 一种用于物联网的物体接入和群组交互方法
US20160205106A1 (en) * 2015-01-12 2016-07-14 Verisign, Inc. Systems and methods for providing iot services
CN104639625B (zh) * 2015-01-27 2018-05-01 华南理工大学 一种基于mqtt的数据集中器采集控制方法、装置及***
US10033589B1 (en) * 2015-09-30 2018-07-24 Juniper Networks, Inc. Management of services to subscriber groups in a distributed service plane environment
CN106210084B (zh) * 2016-07-15 2019-06-11 常州市小先信息技术有限公司 一种基于mqtt的消息插播方法
US10645181B2 (en) * 2016-12-12 2020-05-05 Sap Se Meta broker for publish-subscribe-based messaging
KR102004160B1 (ko) * 2016-12-22 2019-07-26 경희대학교 산학협력단 사물인터넷 환경에서 클라이언트 식별자를 이용하여 클라이언트 노드들을 논리적으로 그룹화하는 장치 및 방법
CN106603565A (zh) * 2016-12-30 2017-04-26 上海浦东软件园汇智软件发展有限公司 一种数据传输、显示的方法及设备

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102308548A (zh) * 2009-02-12 2012-01-04 国际商业机器公司 在发布和定制引擎中引入加密、认证和授权
CN107567700A (zh) * 2015-03-10 2018-01-09 英特尔公司 使用基于密钥的加入协议的物联网组形成
WO2017143227A1 (en) * 2016-02-19 2017-08-24 Intel Corporation Internet-of-things device blank

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3734913A4

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111371889A (zh) * 2020-03-03 2020-07-03 广州致远电子有限公司 消息处理方法、装置、物联网***和存储介质
CN111371889B (zh) * 2020-03-03 2023-03-31 广州致远电子股份有限公司 消息处理方法、装置、物联网***和存储介质
CN111416867A (zh) * 2020-03-25 2020-07-14 上海商米科技集团股份有限公司 不同设备间的消息处理方法、服务器和计算机存储介质
CN114979198A (zh) * 2022-04-19 2022-08-30 深圳市爱为物联科技有限公司 一种适用于物联网平台通用数据处理的解决方法

Also Published As

Publication number Publication date
EP3734913A4 (en) 2021-02-24
CN110048927B (zh) 2020-12-15
CN110048927A (zh) 2019-07-23
EP3734913A1 (en) 2020-11-04
US11411897B2 (en) 2022-08-09
US20200344189A1 (en) 2020-10-29

Similar Documents

Publication Publication Date Title
WO2019141111A1 (zh) 通信方法和通信装置
US11265218B2 (en) Configuration management method and apparatus, and device
KR102046700B1 (ko) 메시지 버스 서비스 디렉토리
CN106230896B (zh) 一种消息推送方法、装置及***
KR101769386B1 (ko) M2m 시스템에서 통지 메시지 전달 방법 및 이를 위한 장치
WO2018133454A1 (zh) 远程服务访问路径控制方法和相关设备
EP3861706B1 (en) Framework for dynamic brokerage and management of topics and data at the service layer
US8887243B2 (en) Integrated security platform
US20170373860A1 (en) Routing cloud messages using digital certificates
KR20040103980A (ko) 컨텐츠 전송 네트워크(ｃｄｎ) 인터네트워킹, 각각의네트워크 및 인터페이스 구성요소를 실행하는 방법
WO2018010626A1 (zh) 云端数据组播方法、***和计算机设备
CN109787992A (zh) 一种通过视联网访问专网的方法和装置
WO2021169291A1 (zh) 发布路由的方法、网元、***及设备
CN107944461B (zh) 一种数据处理方法、装置和设备
Pfrommer et al. Hybrid OPC UA and DDS: Combining architectural styles for the industrial internet
JP2024511907A (ja) ネットワーク機能登録方法、発見方法、装置、デバイス及び媒体
CN109167683A (zh) 一种管理微信企业号和服务号的服务***
WO2012113198A1 (zh) 一种通信***和信息交互方法
US20210211417A1 (en) Methods and systems to automatically interconnect devices and applications over multi-cloud providers and on-premises networks
CN109716310A (zh) 用于内容分发***的服务器装置、传输装置和程序
CN102035725B (zh) 一种非对称路由下单向流uri的关联技术***及其方法
WO2017198088A1 (zh) 资源订阅方法、资源订阅装置和资源订阅***
Zhai et al. An improved DDS publish/subscribe automatic discovery algorithm
CN113595912B (zh) 5GLAN中基于IPv6扩展报头的一对多通信方法及装置
CN117440446B (zh) 一种基于数据分发服务的数据传输方法和装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19740907

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019740907

Country of ref document: EP

Effective date: 20200727