CN106878446A

CN106878446A - The means of communication

Info

Publication number: CN106878446A
Application number: CN201710139962.9A
Authority: CN
Inventors: 丁钊; 周高强; 王留涛; 阎孝军; 韩学志; 任国军; 杨杰
Original assignee: DASHENG MICROGRID TECHNOLOGY Co Ltd
Current assignee: DASHENG MICROGRID TECHNOLOGY Co Ltd
Priority date: 2017-03-10
Filing date: 2017-03-10
Publication date: 2017-06-20

Abstract

The embodiment of the present invention discloses a kind of means of communication, and data and remote control are transmitted in Internet of Things and internet environment to solve the problems, such as that industrial Internet of Things application is not suitable for commercial Application using traditional industry local communication agreement and general internet communications protocol.The method includes：Issue terminal sets up communication connection with cloud server respectively with terminal is subscribed to；The subscription terminal is by the cloud server to the issue terminal topic of subscription；The issue terminal pushes the message of the topic of subscription by the cloud server to the subscription terminal.

Description

Communication method

Technical Field

The invention relates to the field of industry, in particular to a communication method.

Background

With the development of the internet of things technology, the internet of things technology is applied more and more in the industrial field, more and more industrial applications are transferred to the cloud, and the transmission of industrial application data through the internet and the internet of things becomes increasingly important. In the application of the traditional industrial automation system, the transmission of the application data is in a local area network or a special wide area network, and the network itself ensures the timeliness and safety of data transmission to a great extent. In a typical internet application, data access to a server by a client is emphasized, and modification of server resources such as a database by a service provided by the server is often subject to a great deal of concurrent access pressure. The application of the industrial Internet of things is different from the application of the industrial Internet of things and the application of the industrial Internet of things, and the application data of the industrial Internet of things is not limited to a local area network or a private network but enters cloud application through the Internet of things and the Internet; concurrent access pressure on the client is relatively small, but a great deal of control demand is required on intelligent equipment in the Internet of things, and the requirement on safety is higher in the civil field.

Disclosure of Invention

The embodiment of the invention provides a communication method, which aims to solve the problem that the traditional industrial field communication protocol and the common Internet communication protocol used in the application of industrial Internet of things are not suitable for the industrial application of the Internet of things and the Internet environment for data transmission and remote control.

The embodiment of the invention adopts the following technical scheme:

a method of communication, comprising:

the publishing terminal and the subscribing terminal are respectively in communication connection with the cloud server;

the subscription terminal subscribes a theme to the publishing terminal through the cloud server;

and the publishing terminal pushes the message of the subscription topic to the subscribing terminal through the cloud server.

Based on the communication method of the technical scheme, the publishing terminal and the subscribing terminal are respectively in communication connection with the cloud server; the subscription terminal subscribes a theme to the publishing terminal through the cloud server; and the publishing terminal pushes the message of the subscription theme to the subscribing terminal through the cloud server.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and together with the description, serve to explain the principles of the invention.

Fig. 1 is a flowchart illustrating a communication method according to an embodiment of the present invention.

Fig. 2-34 are schematic diagrams illustrating a message structure according to an embodiment of the present invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, not all, embodiments of the present invention. All other embodiments, which can be obtained by a person skilled in the art without any inventive step based on the embodiments of the present invention, are within the scope of the present invention.

Example 1

As shown in fig. 1, an embodiment of the present invention provides a communication method, including:

11. the publishing terminal and the subscribing terminal are respectively in communication connection with the cloud server;

12. the subscription terminal subscribes a theme to the publishing terminal through the cloud server;

13. and the publishing terminal pushes the message of the subscription topic to the subscribing terminal through the cloud server.

In the embodiment of the invention, the communication between the publishing terminal and the server and between the subscribing terminal and the server is realized through the following processes: 1. connection and authentication flow between a publisher or subscriber (client) and a proxy (server). 2. Link test flow between a publisher or subscriber (client) and a proxy (server). 3. Topic configuration flows between publishers, brokers and subscribers (including topic registration, topic deletion and topic notification). 4. Topic subscription flow (including subscription and unsubscribe) between subscribers and proxies. 5. A topic publishing process between a publisher and a broker. 6. Topic push flow between the proxy and the subscriber. 7. Topic setting flow among subscribers, agents and publishers. The flow diagram is shown in fig. 2.

In order to implement a method for agent-based subscription/publish message transmission and remote control for the industrial internet of things in the embodiment of the present invention, 28 message types are used in the above process, and these different types of messages have similar message structures, that is, the whole message is composed of two parts, a message header and a message body. The message header is fixed to 2 bytes, and includes a message type of 5bits and a message body length of 11bits, as shown in fig. 3. In the embodiment of the invention, different message types and different message main body formats are different, and the specific format is detailed in the flow. The values of the message type are given in the table above. The length of the message is 0-2047, and the unit is byte. To minimize network overhead, the message length is typically less than 1400 bytes.

In the embodiment of the invention, a topic subscription process between a subscription terminal (subscriber) and a cloud server (broker). The method comprises the following specific steps:

when the corresponding topic message is published by a publishing terminal (publisher), the browser can actively push the topic message to the subscriber as soon as possible. The message format for subscribing to a topic from a browser is shown in detail in fig. 4.

The theme configuration information is json character strings, and whether encryption is carried out depends on the configuration during connection.

Each attribute of the Json object is a publisher set array of subscription keywords, and the attribute name is the name of the user registered by publisher at brooker.

The Broker implements the subscription record by querying each subscription keyword. The subscription keywords support several matching patterns: the topic identifications are exactly matched, namely the subscription keywords are identical to the topic identifications. The topic identification is fuzzy matching, namely the subscription keyword is the same as the part of the topic identification. The subscription groups are exactly matched, i.e. the subscription keywords are identical to a certain subscription group name. The subscription group is fuzzy matched, i.e. the subscription keyword is partially identical to the subscription group name. Where fuzzy matches are supported wildcards, asterisks (. Asterisks (#) represent 0 or more characters. Question mark (. Topics that can meet the matching conditions are added to the subscription set of the subscriber.

After the SUBSCRIBE, browser parses the subscription keywords of the SUBSCRIBE message, queries each subscription keyword and adds the subject meeting the conditions into the subscription set of the SUBSCRIBE. The subscription set may be implemented by a configuration file or a database table or a database document (e.g. mongodb), for example, the subscription relationship is recorded using a database table subst (ID, TOPICID, substriberid), ID being a meaningless integer ID for avoiding record duplication, TOPICID being a topic identification, substriberid being a subscriber ID. After the recording is completed, the broker sends an acknowledgement message (SUBACK) to the substriber, as shown in fig. 5.

UNSUBSCRIBE UNSUBSCRIBEs a topic to a brooker via an UNSUBSCRIBE message when the subscriber no longer needs to subscribe to the topic or topics. The specific format is shown in fig. 6.

The unsubscribe keyword is a json character string in the UTF-8 encoding format, and all the unsubscribe keywords are used as elements of an unsubscribe array, and the specific format is shown in fig. 6.

After the unsubscriber analyzes the UNSUBSCRIBE keywords of the UNSUBSCRIBE message, inquiring each UNSUBSCRIBE keyword and deleting the subject meeting the conditions from the subscription set of the unsubscriber. The subscription set may be implemented by a configuration file or a database table or a database document (e.g. mongodb), for example, the subscription relationship is recorded using a database table subst (ID, TOPICID, substriberid), ID being a meaningless integer ID for avoiding record duplication, TOPICID being a topic identification, substriberid being a subscriber ID.

After the deletion of the eligible records is completed, the broker sends an acknowledgement message (UNSUBACK) to the subscriber, as shown in FIG. 7.

In the embodiment of the present invention, a theme publishing process between publisher and broker is specifically as follows:

PUBLISH, which is used for publishing a subject message to a browser when a new message (or data) is generated, and a specific message format is shown in fig. 8. Wherein the first 7 bytes are in fixed format, and the latter is in variable format.

The fixed format includes the following items: message sequence number, location Byte 2-Byte 3, 2 bytes, high Byte before and low Byte after. The sequence of message transmission at different time points of the same subject is represented, the message sequence number is maintained by the publisher, starting from 0, the message sequence number is increased by 1 each time the message is transmitted, and the counting is started from 0 again after the maximum value of 65535 is reached. An increase (change) in the message sequence number indicates that a new message is generated. Function flag bit, position Byte4, 1 Byte. Encrypt message, position bit7, 0 indicating that the current message is not encrypted, and 1 indicating that the current message is encrypted. The data encryption switch of the PUBLISH message does not use the setting in the CONNECT message, but is determined by the encryption flag bit in each message, if encrypted, the variable format content starting from Byte7 is encrypted, and the related parameters such as the encryption algorithm use the setting of the CONNECT message. The confirmation is needed, and the position bit6, 0 indicates that no confirmation is needed after the current PUBLISH message is received by the broker; 1 indicates that the current PUBLISH message needs to be confirmed by using the PUBLISH message after being received by the browser. The retransmission message, position bit5, 0 indicates normal transmission, and 1 indicates that the message is a retransmission message. When the acknowledgement message of the broker is not received within the timeout period (using the message timeout period set in the CONNECT message), the publisher retransmits the PUBLISH message to the broker, sets the retransmission flag to 1, retransmits for 3 times at most, and if the failure still occurs, it indicates that the link has a problem and needs to be reconnected. When the retransmission flag is 1, the message sequence number is not changed. The timestamp, position bit4, 1, indicates that the message contains a timestamp and 0 indicates that the message does not contain a timestamp. Topic data type (format), location Byte5, indicates the data type or format of the topic data within the message for the broker or substriber to parse, 0: RAW, original byte stream, application format agreed by both publisher and subscriber, 1: UINT8, unsigned 8-bit integer, 1 byte, 2: INT8, signed 8-bit integer, 1 byte, 3: UINT16, unsigned 16-bit integer, 2 bytes, 4: INT16, signed 16-bit integer, 2 bytes, 5: UINT32, unsigned 32-bit integer, 4 bytes, 6: INT32, signed 32-bit integer, 4 bytes, 7: UINT64, unsigned 64-bit integer, 8 bytes, 8: INT64, signed 64-bit integer, 8 bytes, 9: float, signed single precision floating point, 4 bytes, 10: double, signed double precision floating point, 8 bytes, 11: pool, boolean, 1 byte, 0x00 for false, 0xFF for true, 12: UTF8string, UTF-8 character stream, no string end marker, 13: ASCII string, ASCII code character stream, no string end mark, 14-127: retention, 128-255: undefined, custom extension is agreed by both publisher and subscriber, and when the unit data type is 0, 12-15, and non-numerical value type subject data is transmitted, each message can only transmit one subject data unit. The string type message, which uses UTF-8 format string, N bytes, must be smaller than the maximum message length (1400) "Unit data type" which determines the byte length of "data" in the "subject data Unit". The subject address, positions Byte 6-Byte 7, occupy 2 bytes, with the high Byte preceding and the low Byte following, and has an effective range of 0-65535. The theme address is a representation form of the theme identification (theme ID) in the publisher, replaces the lengthy character theme identification, can effectively reduce the network overhead and save the flow.

The variable format includes the following items: timestamp, if the timestamp function is enabled at the "timestamp" function flag bit, the "subject address" will be followed by a 9 byte timestamp. The format is calendar time of 9 bytes, as shown in fig. 9.

Subject data, the "subject address" will be followed by the subject data content if the timestamp function is not enabled in the "timestamp" function flag bit, whereas the subject data follows the timestamp, i.e. starting from Byte 16. The specific format of the subject data is determined by the "subject data type (format)".

And the PUSCK is used for confirming the PUBLISH message by the broker. Not all PUBLISH messages need to reply to an acknowledgement, and only when the "acknowledgement needed" flag bit in a PUBLISH message is set to 1, must the message reply to an acknowledgement using a PUBLISH message. Before the replay, the parsing and caching of the subject data in the PUBLISH message must be completed.

The message format is shown in fig. 10. The "message sequence number" must be the same as the "message sequence number" of the acknowledged PUBLISH message, which indicates that the message with the sequence number has been successfully parsed and cached, and is acknowledged. The Broker does nothing to "message sequence number", and copies it from the PUBLISH message to the value PUBLISH message only upon acknowledgement, with the message sequence number maintained by publisher.

In one embodiment, the step of establishing communication connection between the publishing terminal and the subscribing terminal and the cloud server respectively comprises: and the issuing terminal and the subscribing terminal register and authenticate identities in an auditing mode before connecting to the cloud server every time.

The connection and authentication process between the publisher, the subscriber and the brooker in the embodiments of the present invention are described in detail below. The publisher and the substriber are clients (in the connection and authentication process, clients are used to refer to publisher and the substriber), and the browser is a cloud server (server).

Before each client is connected to the server for the first time and authenticated, the identity registration and authentication (for example, the registration and key exchange are completed by using a secure WEB service site) need to be performed in a manual auditing manner, and the specific steps are as follows:

the Server makes its own private key and public key. The Server uses the openssl command line tool to generate a pair of keys in 1024-bit PKCS #8 format, namely a public key and a private key. In a specific implementation, the server key pair can be updated periodically by an openssl tool provided by the server. Then actively pushing the server public key to each client by using a special theme. Detailed in the following (PUSH message).

The Client makes its own private and public keys. The Client uses an encryption method agreed with the server to make a private key and a public key of the Client. The Client also generates a pair of keys in 1024-bit PKCS #8 format, namely a public key and a private key, using the openssl command line tool.

And registering the user. The Client registers a user on the server and sets a corresponding password, the server assigns a unique Client ID (for example, a record is newly added in a Client table, the ID of the record is 1), and the format of the Client ID is 32-bit unsigned integer (occupies 4 bytes). The Client downloads the ClientID from the Server and saves it properly.

A key is exchanged. The Client uploads the public key of the Client to the Server, and the Server stores the public key (the specific storage mode is not limited, and the public key can be stored in a database, a file or the like, for example, in a pubkey field of a Client table). Meanwhile, the Client downloads a public key file (key) of the Server from the Server and properly saves the public key file.

And (4) automatically executing the process. During normal communication, the following steps (automatically completed through a program) are carried out, specifically as follows:

and in CONNECT, the client sends a connection request message to the server, and the message main body carries the client ID encrypted by using the server public key. First, a publisher or a subscriber establishes a communication link with a proxy CONNECT message, and the specific message format is shown in fig. 11. The CONNECT message includes relevant information such as a protocol version number, message timeout time, and a message encryption method.

The protocol version. The version format is V major version number. And V1.0. The major version number represents a large change of the protocol content, downward compatibility is not necessarily guaranteed, the minor version number is a small change, and programs of different minor versions can be compatible with each other when the same major version number exists. Byte1 is the protocol major version number and Byte2 is the protocol minor version number.

Message timeout time. The time is used for link test, namely, if any legal message of the other party is not received in the time period, the communication is determined to be interrupted.

And (4) message encryption mode. The RSA public key and private key mentioned above are used for identity authentication of publishers and subscribers, and in the process of message transmission, the use of such asymmetric encryption method will greatly reduce the real-time performance of message transmission, while the symmetric encryption speed is fast, so that in the actual message data transmission, the symmetric encryption algorithm is selected, for example, the encryption mode when data transmission is performed after the current connection is established is determined by the encryption-related information set in AES, Blowfish, Byte 6.

A message encryption algorithm. 0: no encryption, 1: blowfish, 2: in AES, the encryption algorithm selection here determines the length of the random cipher generated by the proxy (server) during CONNACK, and the random cipher is the key used during encrypted data transmission during the period of validity of the connection (before disconnection). When no encryption is selected, the random password is only used for identity authentication, and the length is generally 32. When Blowfish is selected, the random cipher length is 2-56 (16-448 bits), generally 32. With AES chosen, the random cipher length is 16(128bits), 24(196bits) or 32(256bits), typically 32.

A message encryption mode. 0: no encryption, 1: ECB, 2: CBC, 3: CTR, 4: OFB, 5: and (5) CFB (computational fluid dynamics).

A message encryption mode. 0: no encryption, 1: zeropadding, 2: pkcs5padding, 3: pkcs7padding, 4: iso10126, 5: ansix 923. Specifically, please refer to the related concepts of the encryption algorithm for reading the data by itself, which will not be described herein.

Fig. 12 is an example of a data fill message:

and the server decrypts the client ID by using the private key and finds out the corresponding client public key and private key. For example: after the private key of the server is used for decryption (an opennssl tool is used), the clientID is 1, then the record with the ID of 1 is searched in the client table, and after the record is found, the value of the field pubkeye of the record is read, namely the public key corresponding to the clientID.

The Server sends a connection confirmation message to the client, and if the connection is successful, the Server generates a random password with a length of 25 bits (for example: 7lr5BR7 aV! L2TYkNR3J9 i! 5zS), and the message body carries the random password encrypted by using the Server private key.

The random number of secret codes here relates to the encryption algorithm set at the time of connection. The specific length is described in detail in CONNECT. The message structure is shown in fig. 13.

Wherein: the connection return state code is the connection result returned to the Client by the Server. The values have the following meanings: 0: successful connection, 1: the connection fails because the client id ciphertext fails to be decrypted using the server private key. 2: the connection fails because the ClientID does not exist. Fig. 14 is an example of a data fill message in accordance with an example.

AUTHEN, the client decrypts the random password using the server public key. In the RSA key pair (public and private keys), the ciphertext encrypted using one of the keys can be decrypted necessarily using the other key, so the random cipher encrypted using the private key of server can only be decrypted using the public key of server.

If the decryption fails, the server identity is suspicious, and no message is sent to the server. And if the decryption is successful, the client sends an authentication message to the server, and the message main body carries a random password encrypted by using the client private key.

The message structure is shown in fig. 15. Fig. 16 is an example of a data stuff message by example.

AUTHACK, server uses client public key to decrypt random cipher, and compares whether they are consistent, and returns the authentication result to client to inform its reason. The message structure is shown in fig. 17. Wherein: the authentication result status code is the authentication result returned by the Server to the Client. The values have the following meanings: 0: successful authentication, 1: authentication fails because decryption of the ClientID ciphertext using the server private key fails. 2: if the connection fails because the random password is wrong, the client identity is suspicious. Fig. 18 is an example of a padding message when authentication is successful:

and the client actively sends a DISCONN message to the server when disconnection from the server is required. The message structure is shown in fig. 19.

In one embodiment, after the publishing terminal and the subscribing terminal establish communication connection with the cloud server respectively, the method further includes: and the issuing terminal and the cloud server perform link test, and the subscribing terminal and the cloud server perform link test.

The embodiment of the invention discloses a link test flow among a publisher, a substiber and a brooker. The publisher and the subscriber are clients (clients), and the browser is a server (server). The link test is used for testing whether the link is normal or not when the preset timeout time (set by the CONNECT message) is reached between the client and the server. The timeout is performed by the client side and the server side respectively, and is started after any message is received. If the client end does not receive any message from the server end within the overtime time, the client end judges that the client end is disconnected from the server and tries to reconnect; the server end distributes a timeout timer for each client, and if the server end does not receive any message from a client end within the timeout time, the server end judges that the connection between the client and the server is disconnected, and clears the setting (information set by the CONNECT message) in the current connection.

The specific flow of performing the link test is as follows:

LINKTEST, client sends link test message to server. The message format is shown in fig. 20.

LINKACK, server sends link confirmation message to client. The message format is shown in fig. 21.

In one embodiment, the step of establishing communication connection between the publishing terminal and the subscribing terminal and the cloud server respectively comprises: the publishing terminal registers with the cloud server, and the subscribing terminal registers with the cloud server.

The embodiment of the invention also comprises topic configuration (registration, deletion and notification), and a topic configuration process (comprising topic registration, topic deletion and topic notification) between the publisher, the agency and the subscriber. The method comprises the following specific steps:

the REGIST, publish sends the topic registration message to the broker, the message body carries the topic configuration information, and the topic configuration information (the format of which needs to be provided) includes: a topic identification (UTF8 string), a topic message quality of service level (up to once, down to once, once only), etc.

The theme configuration information is a json character string in UTF-8 format. The specific format is as follows:

{

"ID": 1# workshop _2# pipeline _3# equipment _ analog 1 ",

“dest”:“”,

“addr”:1,

“type”:”INT32”,

"group" [ "subscription group 1", "subscription group 2" ],

“cacheNum”:100,

“setting”:{

“guardTime”:5000,

“needApproval”:1

},

“retain”:true,

“deleted”:false

}

wherein, the 'ID' is a subject mark, the value is a character string type, and letters, numbers, _ (underline), #, $ and Chinese characters in UTF-8 coding can be used. Where "_" underlining is used for natural grouping, this can be used to automatically subscribe to topics with the same prefix at the time of subscription, as will be described in detail in the topic subscription flow. "desc" is a subject description, the value is a string type, and any UTF-8 character can be used. "addr" is the internal address of the subject, an indication of the address within the publisher, and different publishers may have the same internal address. The maximum value is 65535, i.e. a maximum of 65535 topics are supported by each publisher. "type" is the subject message data type, with values of enumeration strings, valid values as follows: UINT8, INT8, UINT16, INT16, UINT32, INT32, UINT64, INT64, Float, Double, pool: a boolean type.

string: the type of string. "group" is a topic grouping with values of an array of strings. Each topic may be added to multiple groupings, and when a grouping is subscribed, the topics in the grouping are all subscribed. When the group array is empty, grouping is automatically allocated according to the ID, and each element in the array represents one grouping. Absent this item setting, the default value is [ ].

The "cacheNum" is the number of cache entries, and the value is an integer, and ranges from 0 to 1000. The size of cacheNum determines the number of messages that the proxy (server) caches the topic. Absent this setting, the default value is 100.

The "setting" object relates to the configuration of the theme settings. A value of null indicates that the topic is not allowed to be set, i.e. read-only topics. When the value is an object and includes "guardTime" and "needpropval", it indicates that the theme is allowed to be set, i.e., is a readable and writable theme.

guardTime

Guard time in seconds. The range is as follows: 0 to 3600. The maximum protection time does not exceed 1 hour. When a setting request (SETREQ message) is executed by the same topic, no new setting request is executed within guardTime milliseconds. When guardTime is equal to 0, it means that the guard time is not required and a new setting request can be immediately performed. Absent this setting, the default value is 0.

needApproxval, requiring approval, Boolean values. true needs to be approved, that is, after the topic receives the request of "SETREQ", the topic needs approval of the subscribers with higher authority levels, and then the true can be executed. The approver needs to be specified in "SETREQ". false does not require approval, meaning that it can be performed directly without the consent of other subscribers. Absent this item setting, the default value is false.

"retain" is a configuration reservation flag with a boolean value. true indicates that the theme configuration remains on the proxy (server), even after the current connection is broken. false indicates that the theme configuration is not retained, i.e., is cleared when the connection is disconnected. Absent this setting, the default value is true.

"deleted" is a "deleted" flag. Indicating that the topic has been deleted in the proxy server. This attribute is only used when the agent notifies (REGNOTICE) to the subscriber that the topic has been deleted, and may be omitted when registering the topic (REGIST). Attributes other than "ID" and "deleted" may be omitted when the Notification (REGNOTICE) topic is deleted.

If the encryption algorithm of data transmission is set during connection, the json character string configured on the theme is encrypted by using the configured encryption algorithm and a key (random password) and then is refilled.

And after the REGACK and the broker receive the REGIST message of the publisher, analyzing the theme configuration information according to the data encryption mode set by the CONNECT message, and verifying the validity of the configuration information. If the theme configuration is valid, the theme configuration is stored in the server, and the storage mode can be selected according to the actual situation, such as using a configuration file, a database table and the like. For example, the TOPIC configuration is stored using a database table TOPIC (ID, dest, publisher ID, addr, Qos, type, group, cacheNum, setEnable, retain, deleted), where the meaning of the fields in the table is consistent with the attributes of the json object of the TOPIC configuration in REGIST, except that the publisher ID is added to indicate which publisher the TOPIC configuration belongs to.

If the theme configuration information is invalid, a REGACK message is sent to the publisher to inform the publisher of the failure reason.

The format of the REGACK message is shown in fig. 22. The valid values of the registration results are as follows: 0: successful registration, 1: registration failure because a subject Identification (ID) already exists, 2: registration failure because the subject Identification (ID) is invalid, 3: registration failure due to Qos invalid, 4: registration failure due to type invalidation, 5: registration failure due to group invalidation, 6: registration failure because cacheNum is invalid, 7: registration failure due to setEnable invalid, 8: registration fails because retain is invalid.

After the registration fails, the publisher should record the subject configuration information and reasons of the failure for the maintenance personnel to check.

And the REGCOMP sends a REGCOMP message to the broker by the publisher after the registration of all the topics needing to be registered is completed, and the completion of the registration of the topics is indicated. The message format is shown in fig. 23.

REGNOTICE, there are two cases of topic configuration notification.

First, after a new subscriber is connected to a browser, the new subscriber is notified of the existing theme configuration. At this time, all the current topics of the browser are configured to form a unified json character string which is notified to the new subscriber through REGNOTICE. If the length of the json character string exceeds the maximum length, the character string is divided and sent by a plurality of messages, and the message format is detailed.

Secondly, after the brooker receives the REGCOMP message of the publisher, it indicates that the topic registration of the publisher is completed, and at this time, the brooker starts to sequentially notify all the subscribers of the topic configuration for which the new registration is successful. As in the previous case, the theme configuration will be packed into the message using json string format, and if the maximum message size is exceeded, it will be sent in multiple messages. The message format is shown in fig. 24.

Wherein,

end mark: indicating whether the message is the last message of REGNOTICE. If the REGNOTICE message only needs one, namely the json character string of the theme configuration is within the maximum allowed length (1400 bytes) of a single message, the end flag is directly set to 1. If multiple messages are needed, the end flag is set to 1 only when the last message is sent, and the others are set to 0.

Retransmission flag: indicating whether the message is a retransmitted message. Each redirect message needs to confirm the redirect message, and when the confirmation is not received within a specified timeout period (the timeout period set in the CONNECT message), the broker may retransmit the redirect message, each message is allowed to be retransmitted at most 3 times, and after 3 times of retransmission, the connection between the broker and the subscriber is disconnected if the redirect message confirmation is not received.

Topic configuration notification sequence number: occupies 15bits and is an integer without sign number.

The method is used for representing the sequence of the messages when a plurality of REGNOTICE messages are sent, and is used for restoring the json character string configured for the subject after the brooker receives the regNOOTICE messages.

The serial number is maintained by the brooker, and when receiving the subscriber's REGNOTICEACK confirmation message and confirming the REGNOTICE message with the end mark 1, the brooker zeroes the serial number for use in next notification configuration.

Theme configuration information: similar to the subject configuration information format in the REGIST message. The difference is that in the REGIST message, the subject configuration is a single configuration object (referred to herein as a json object, i.e., the contents of a pair { }). The theme configuration information in the communications apparatus is composed of theme configurations of multiple publishers, so each attribute of the top-level object is a theme configuration of one publisher, the attribute name is ID (assigned ClientID when the user is registered on the broker server) or name (registered user name on the broker server), the type of the attribute name is json array, and each array element in the configuration array of each publisher is a theme configuration object (i.e. the theme configuration information in the region message).

For example, a configuration consisting of two configuration arrays of publishers. It should be noted that the last object in the array cannot be followed by a comma, "and reference is specifically made to the json rule, which is not described herein again.

As to encryption. If a data encryption algorithm is set during connection and the theme configuration information is to be sent in a plurality of messages, the json character string of the theme configuration information is firstly divided and encrypted in each message respectively.

REGNOTICEACK, topic configuration notification confirmation. Receipt of each REGNOTICE message by a substiber requires an acknowledgement using the REGNOTICEACK message. Upon acknowledgement, the end flag, retransmission flag, and topic configuration notification sequence number are the same as the acknowledged REGNOTICE message. After receiving the REGNOTICE message with the "end mark" of 1, the subscriber reassembles all received topic configuration information fragments carried in the REGNOTICE message according to the sequence of the message sequence number, analyzes the topic configuration information therein, and stores the topic configuration information (for example, directly stores the topic configuration information in a file or a database table) for use when subscribing the message to the browser.

The specific message format is shown in fig. 25.

DELETE, DELETE topic configuration. When the publisher no longer provides message updates for a topic or topics, a topic deletion message may be sent to the broker indicating a desire to delete the relevant topic configuration from the broker. The specific message format is shown in fig. 26.

The topic identification array is a set of topic identifications desired to be deleted, and topic addresses are used in the set (topic addresses are representation forms of the topic identifications in publisher, and are specifically described in PUBLISH messages).

DELACK, acknowledging the delete topic configuration. The Broker confirms to the publisher the result of the deletion of the theme topic, deleted or failed to delete. The specific message format is shown in fig. 27.

Wherein, the deletion result is: 0: successful deletion, 1: the deletion fails. The subject configuration flow alternative flow is implemented via REGIST, REGACK, REGCOMP, REGNOTOICE, REGNOTOICEACK, DELETE, and DELACK messages. When the operation of the system does not need manual participation, the mapping of the character string form and the digital ID form of the theme identification and the configuration of the theme are agreed before the system is on line, and the publisher, the substriber and the brooker are completely known, the process does not need to be realized in the system, and only configuration files (generated by tools or manually made) need to be made according to the agreement, so that the publisher, the substriber and the brooker can automatically read the consistent configuration information.

In one embodiment, further comprising: and pushing the message of the subscription theme between the publishing terminal and the cloud server according to a preset flow.

In one embodiment, the messages of the subscription topics are pushed between the cloud server and the subscription terminal according to a preset flow.

In one embodiment, the subscription theme is determined between the cloud server and the subscription terminal according to a preset flow.

In one embodiment, the subscription theme is set between the cloud server and the subscription terminal according to a preset flow.

The theme push flow between the browser and the subscriber in the embodiment of the invention is as follows:

and the PUSH message is used for pushing the theme data published by the publisher to the subscriber by the broker. The PUSH message is identical to the PUBLISH message in the same format except for the type of the message. The specific format is not described in detail, and refer to PUBLISH in detail, note that the message type used needs to be changed from PUBLISH (19) to PUSH (21).

In addition, the message sequence number is different from the content in PUBLISH. The sequence number in the PUSH is maintained by the browser for each subscriber, that is, in the browser, one PUSH sequence number should be reserved for each subscriber to ensure the sequence in the process of pushing the theme data to each subscriber.

PUSHOCK, a PUSHOCK message is used to acknowledge a PUSH message, acting similar to a PUSCK. In contrast, the PUSHOCK is a message sent by the substriber to the browser. The specific format is not described in detail, and the details of the heartbeat are referred to, note that the message type used needs to be changed from the heartbeat (20) to the heartbeat (22).

The theme setting process between the brooker and the substriber in the embodiment of the invention is as follows:

the SETREQ message is used for the substriber to request the brooker to set a certain theme, namely to request to change the state and the attribute of the theme, so that the publisher executes certain operation or action. The specific format is shown in fig. 28:

the message sequence number is maintained by a subscriber, the message sequence number is increased by 1 when one SETREQ message is sent, and the message sequence number starts from 0 again after the SETREQ message reaches the maximum value.

The encrypted message, position Byte4 bit 7. A value of 1 indicates that the message needs to be encrypted, ranging from Byte5 to the end. When the value is 0, no encryption is performed.

The approval mode, position Byte4 bit4, with a value of 1 indicates that all approvers are required to approve the setup request. A value of 0 indicates that the setup request can be performed with the consent of any one of the approvers.

The number of approvers, positions Byte4 bit 3-bit 0. With a value equal to 0, no approval is required. If the value is greater than 0, the number of subscribers who need to approve the setting request is increased. It needs to be consistent with the configuration of the set subject in the register.

The issuer ClientID, the positions Byte 5-Byte 8, 32-bit unsigned integer. The publisher ClientID tells the broker to which publisher the topic set by the message belongs.

The ClientID of the approvers is the positions Byte9 to Byte 9+ 4A-1, and A is the number of the approvers. Each approver ClientID is a 32-bit unsigned integer. The approver is a subscriber who needs to approve the setting request in the current SETREQ message, and the approver can be provided with a plurality of approvers.

Topic data type (format), location Byte 9+ (4 × a), represents the data type or format of the topic data in the message for the convenience of broker or substriber parsing, see PUBLISH message for a detailed description.

The subject addresses, positions Byte 8-Byte 9, range from 0 to 65535. The message requires the address of the topic to be set. Together with the publisher ClientID, the uniqueness of the theme that needs to be set is guaranteed.

Setting data, the specific length and value are determined according to the set subject address, the length and format occupied by different subject types are different, and the related description in the PUBLISH message is specifically referred to.

SETREQACK, SETREQACK message is used to acknowledge the SETREQ message. The specific message format is shown in fig. 29.

It must be confirmed that each secreq message requires an acknowledgment reply using SETREQACK, the sequence number in SETREQACK being the same as the sequence number in the secreq message that the message acknowledges.

And sequentially sending, wherein the message sequence number is used for uniquely identifying one SETREQ message, and ensuring the sequence of the messages, and the next SETREQ message can be sent only after the SETREQACK messages of the broker are received.

If the acknowledgment of the SETREQACK message is not received within the timeout period, retransmission is performed up to 3 times. If the reply cannot be received after 3 times of retransmission, the connection is considered to be disconnected.

As a result, 0: request submission success, 1: request submission fails, publisher does not exist, 2: request submission failure, subject address does not exist, 3: request submission failure, subject read only, not allowed to be set, 4: request submission fails, all approvers do not exist, 5: the request submission fails and all approvers are unsubscribed to the topic.

SETREQCHK, SETREQCHK message is used for the brooker to forward the subject request information of the requestor to the approver. If the number of approvers in SETREQ is 0, then there is no need to send an approval request to the approver using SETREQCHK. The message format is shown in fig. 30.

The message sequence number, positions Byte 2-Byte 3, ranges from 0 to 65535, is maintained by a browser, increases by 1 when sending a SETREQCHK message, and starts from 0 again after reaching the maximum value.

The requestor ClientID, locations Byte5 through Byte8, a 32-bit unsigned integer. The requestor ClientID tells the approver who issued the theme setup request.

The issuer ClientID, positions Byte9 to Byte 12, 32 bit unsigned integer. The publisher ClientID tells the approver which publisher's topic the topic setting request sets.

The topic data type (format), location Byte 13, indicates the data type or format of the topic data in the message for the broker or subscriber to parse, as described in detail in the PUBLISH message.

SETREQCHKACK, SETREQCHKACK message is used to confirm SETREQCHK message and return approval results. The message format is shown in fig. 31.

The message sequence number, the duplicate SETREQCHK message sequence number, and the message sequence number is the same for which the message is acknowledged.

Approval results, 255: by, i.e., agreeing to perform the request, 0: the request is denied, i.e. not approved for execution.

SET and SET messages are used for broker to forward a SETREQ message of subscriber to publisher. After the SETREQ message is approved by the approver, the broker forwards the theme setting request to the publisher by using the SET message. The specific message format is shown in fig. 32. The attributes in the message are the same as those in SETREQ and SETREQHK, and are not described in detail here.

SETACK, SETACK message is used to acknowledge the SET message. The specific format is shown in fig. 33.

The message sequence number, which duplicates the message sequence number of the SET, is the same as the message sequence number of which it acknowledges. Approval results, 0: setting successfully, 1-255: the setting fails, and the specific reason is stipulated by the application.

SETCOMP, SETCOMP message is used to end a theme setup request. A completed theme setting process starts from SETREQ, firstly, a request is sent, then the approval is completed by SETREQCHK, and the theme setting is carried out by using SET after the approval. Each step requires a corresponding ACK message for acknowledgement. After the final SETACK is returned to the broker, the setting result needs to be returned to the requester no matter the setting is successful or failed. The specific message format is shown in fig. 34. Most message attributes are consistent with the meanings in other subject setting message formats, and are not described again.

The different parts are: extension, position Byte4 bit 6. 1 indicates that an extension area is used and 0 indicates that no extension area is used. And setting results, copying the setting results in the SETACK message. An extension area for some custom theme data types (formats). If the predefined setting result cannot meet the requirement, the use of an extension area to describe the setting result can be agreed in advance.

According to the communication method, the publishing terminal and the subscribing terminal are respectively in communication connection with the cloud server; the subscription terminal subscribes a theme to the publishing terminal through the cloud server; and the publishing terminal pushes the message of the subscription theme to the subscribing terminal through the cloud server.

Having described embodiments of the present invention, the foregoing description is intended to be exemplary, not exhaustive, and not limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen in order to best explain the principles of the embodiments, the practical application, or improvements made to the technology in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains.

Claims

1. A method of communication, comprising:

2. The method of claim 1, wherein the establishing, by the publishing terminal and the subscribing terminal, communication connections with a cloud server respectively comprises: and the issuing terminal and the subscribing terminal register and authenticate identities in an auditing mode before connecting to the cloud server every time.

3. The method according to claim 1, wherein after the publishing terminal and the subscribing terminal respectively establish communication connections with the cloud server, the method further comprises: and the issuing terminal and the cloud server perform link test, and the subscribing terminal and the cloud server perform link test.

4. The method of claim 1, wherein the establishing, by the publishing terminal and the subscribing terminal, communication connections with a cloud server respectively comprises: the publishing terminal registers with the cloud server, and the subscribing terminal registers with the cloud server.

5. The method of claim 1, further comprising: and pushing the message of the subscription theme between the publishing terminal and the cloud server according to a preset flow.

6. The method according to claim 1, wherein the messages of the subscription topic are pushed between the cloud server and the subscription terminal according to a preset flow.

7. The method of claim 1, wherein the subscription topic is determined between the cloud server and the subscription terminal according to a preset process.

8. The method according to claim 1, wherein the subscription theme is set between the cloud server and the subscription terminal according to a preset flow.