CN115454615A

CN115454615A - Information processing method and device

Info

Publication number: CN115454615A
Application number: CN202110643227.8A
Authority: CN
Inventors: 胡宇明
Original assignee: China Mobile Communications Group Co Ltd; China Mobile IoT Co Ltd
Current assignee: China Mobile Communications Group Co Ltd; China Mobile IoT Co Ltd
Priority date: 2021-06-09
Filing date: 2021-06-09
Publication date: 2022-12-09

Abstract

The invention provides an information processing method and device, wherein the method comprises the following steps: under the condition that input information of a first thread corresponding to a message queue telemetry transmission MQTT protocol client does not exist, controlling the first thread to enter a blocking state, and releasing a processor time slice occupied by the first thread; executing other threads than the first thread using the released processor time slice. In the information processing method provided by the embodiment of the invention, under the condition that the first thread is determined to have no input information, the first thread is controlled to enter the blocking state and the processor time slice occupied by the first thread is released, so that the first thread in the blocking state can be prevented from occupying the processor time slice. And executing other threads except the first thread by using the released processor time slice, thereby improving the processing efficiency of the processor on other threads.

Description

Information processing method and device

Technical Field

The present invention relates to the field of communications, and in particular, to an information processing method and apparatus.

Background

As is well known, a Message Queue Telemetry Transport (MQTT) protocol is constructed on a network protocol stack, and is widely applied to the field of internet of things connection, so that protocol layer connection and transmission between a client and a server can be realized.

However, when a message is transmitted, the message is often initiated and called in a loop of a thread, which is likely to cause waste of resources.

Disclosure of Invention

The invention aims to provide an information processing method and an information processing device so as to avoid resource waste.

In order to achieve the above object, the present invention provides an information processing method, including: under the condition that input information of a first thread corresponding to a message queue telemetry transmission MQTT protocol client does not exist, controlling the first thread to enter a blocking state, and releasing a processor time slice occupied by the first thread; executing other threads than the first thread using the released processor time slice.

Optionally, when the first thread is a main thread, the input information is information in an input message queue; when the first thread is a sending thread, the input message is information in an output message queue; when the first thread is a receiving thread, the input message is a message sent by a server; wherein the input message queue includes information input to the main thread, and the output message queue includes information processed by the main thread and input to the sending thread.

Optionally, after controlling the first thread to enter the blocking state, the method further includes: and when input information of a first thread corresponding to the MQTT protocol client side is monitored, controlling the first thread to be updated from the blocking state to the awakening state.

Optionally, the method further includes: sending first data information to a server and receiving second data information fed back by the server in an asynchronous communication mode; wherein the first data information comprises input information for the first thread.

Optionally, the sending the first data information to the server and receiving the second data information fed back by the server in an asynchronous communication manner includes: the method comprises the steps of sending first data information to a server through a sending thread, and receiving second data information fed back by the server through a receiving thread, wherein the sending thread and the receiving thread adopt an asynchronous working mode.

Optionally, the method further includes: determining a target communication mode according to the target parameters; the target communication mode is used for communicating with a server, and the target communication mode is a synchronous communication mode or an asynchronous communication mode.

Another embodiment of the present invention provides an information processing apparatus including: the determining module is used for determining that input information of a first thread corresponding to the client of the message queue telemetry transmission MQTT protocol does not exist; the control module is used for controlling the first thread to enter a blocking state and releasing a processor time slice occupied by the first thread; and the control module is also used for executing other threads except the first thread by utilizing the released processor time slices.

Another embodiment of the present invention provides an electronic device including: a processor, a memory and a program stored on the memory and executable on the processor, which when executed by the processor implements the information processing method as described above.

Another embodiment of the present invention provides a computer-readable storage medium on which a computer program is stored, which, when executed by a processor, implements the steps of the information processing method as described above.

The technical scheme of the invention has the following beneficial effects:

in the information processing method of the embodiment of the invention, under the condition that the first thread is determined to have no input information, the first thread is controlled to enter the blocking state and the processor time slice occupied by the first thread is released, so that the first thread in the blocking state can be prevented from occupying the processor time slice. And, by using the released processor time slice to execute other threads except the first thread, the processing efficiency of the processor to other threads can be improved.

Drawings

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

fig. 2 is a schematic diagram illustrating an architecture of an information processing method according to an embodiment of the present invention;

fig. 3 is a second schematic flowchart of an information processing method according to an embodiment of the present invention;

fig. 4 is a third schematic flowchart of an information processing method according to an embodiment of the present invention;

FIG. 5 is a fourth flowchart illustrating an information processing method according to an embodiment of the present invention;

fig. 6 is a fifth flowchart illustrating an information processing method according to an embodiment of the present invention;

FIG. 7a is a sixth schematic flowchart of an information processing method according to an embodiment of the present invention;

fig. 7b is a seventh schematic flowchart of an information processing method according to an embodiment of the present invention;

fig. 7c is an eighth schematic flowchart of an information processing method according to an embodiment of the present invention;

fig. 8 is a block diagram of an information processing apparatus according to an embodiment of the present invention.

Detailed Description

In order to make the technical problems, technical solutions and advantages of the present invention more apparent, the following detailed description is given with reference to the accompanying drawings and specific embodiments. In the following description, specific details such as specific configurations and components are provided only to help the full understanding of the embodiments of the present invention. Thus, it will be apparent to those skilled in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the invention. In addition, descriptions of well-known functions and constructions are omitted for clarity and conciseness.

It should be appreciated that reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

In various embodiments of the present invention, it should be understood that the sequence numbers of the following processes do not mean the execution sequence, and the execution sequence of each process should be determined by the function and the inherent logic of the process, and should not constitute any limitation to the implementation process of the embodiments of the present invention.

It should be understood that the term "and/or" herein is merely one type of association relationship that describes an associated object, meaning that three relationships may exist, e.g., a and/or B may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" herein generally indicates that the former and latter associated objects are in an "or" relationship.

In the embodiments provided herein, it should be understood that "B corresponding to A" means that B is associated with A from which B can be determined. It should also be understood that determining B from a does not mean determining B from a alone, but may be determined from a and/or other information.

Referring to fig. 1, an embodiment of the present invention provides an information processing method, including the steps of:

step 11: under the condition that input information of a first thread corresponding to a message queue telemetry transmission MQTT protocol client does not exist, controlling the first thread to enter a blocking state, and releasing a processor time slice occupied by the first thread.

After controlling the first thread to enter the blocking state, the first thread may temporarily stop receiving or processing the input information. By releasing the processor time slice occupied by the first thread when the first thread is in the blocking state, the occupation of the processor time slice by the first thread in the blocking state can be avoided.

It should be noted that the blocking state can be understood as: an executing thread may relinquish processor use under certain special circumstances (e.g., may be performing a time-consuming input/output operation) and enter a blocking state.

Step 12: executing other threads than the first thread using the released processor time slice.

In the information processing method provided by the embodiment of the invention, under the condition that the first thread is determined to have no input information, the first thread is controlled to enter the blocking state and the processor time slice occupied by the first thread is released, so that the first thread in the blocking state can be prevented from occupying the processor time slice. And, by using the released processor time slice to execute other threads except the first thread, the processing efficiency of the processor to other threads can be improved.

In the information processing method provided by the embodiment of the invention, when the first thread is a main thread, the input information is information in an input message queue; when the first thread is a sending thread, the input message is information in an output message queue; when the first thread is a receiving thread, the input message is information sent by a server; wherein the input message queue includes information input to the main thread, and the output message queue includes information processed by the main thread and input to the sending thread.

It should be noted that the server may be a server providing a platform of the internet of things.

And the receiving thread receives the information sent by the server through a lower protocol stack.

The information processing method provided in the embodiment of the present invention, after controlling the first thread to enter the blocking state, further includes: and when input information of a first thread corresponding to the MQTT protocol client side is monitored, controlling the first thread to be updated from the blocking state to the awakening state.

It should be noted that, after the first thread is updated to the wake state, the first thread may continue to process the input information, so as to perform subsequent operations.

The information processing method provided by the embodiment of the invention further comprises the following steps: and communicating with the server in an asynchronous communication mode.

It should be noted that, in the asynchronous communication mode, after the first data information is sent, the data information can be continuously sent to the server without waiting for the feedback of the server for the first data information (the feedback may be, for example, a message confirming that the first data information is received), so that the efficiency of data sending is improved. Particularly, under the condition of large data volume, the asynchronous communication mode is adopted, so that the data throughput can be improved, and the timeliness of data transmission is ensured.

Of course, a synchronous communication mode may be used to communicate with the server.

The information processing method provided by the embodiment of the invention, which adopts an asynchronous communication mode to communicate with the server, comprises the following steps: the method comprises the steps of sending first data information to a server through a sending thread, and receiving second data information fed back by the server through a receiving thread, wherein the sending thread and the receiving thread adopt an asynchronous working mode.

It should be noted that the sending thread and the receiving thread are two independent threads, and the two threads adopt asynchronous working modes without mutual influence, so that the efficiency of communication with the server can be improved.

The information processing method provided by the embodiment of the invention further comprises the following steps: determining a target communication mode according to the target parameters; the target communication mode is used for communicating with a server, and the target communication mode is a synchronous communication mode or an asynchronous communication mode.

In the synchronous communication method, after the first data information is transmitted, the server needs to wait for feedback of the first data information (the feedback may be, for example, a message confirming that the first data information is received) and then continue to transmit the data information to the server.

The target parameter may be, for example, the size of the data volume, for example, if the data volume is large, an asynchronous communication mode may be adopted, and if the data volume is small, a synchronous communication mode may be adopted. The target parameter may be, for example, the time duration, for example, if it is expected that data is acquired with the time duration, an asynchronous communication mode may be used, and if there is no requirement for the time duration, a synchronous communication mode may be used, or an asynchronous communication mode may be used.

Referring to fig. 2, a schematic diagram of an architecture of an information processing method according to an embodiment of the present invention is shown. In the schematic architecture diagram shown in fig. 2, the MQTT protocol client is composed of three modules implemented by independent threads: MQTT main processing module, MQTT transmitting module and MQTT receiving module. The MQTT main processing module corresponds to an MQTT main thread, the MQTT sending module corresponds to an MQTT sending thread, and the MQTT receiving module corresponds to an MQTT receiving thread. The function of each module is explained below.

MQTT main processing module: the MQTT client main logic processing module is used for realizing the functions of client related structure, entity and callback function initialization, client network and MQTT protocol layer connection, client required theme subscription and receiving maintenance, client required theme publishing and sending maintenance, client error state processing and the like. The MQTT main processing module adopts a working mode of state machine jumping and is divided into an initialization state, a connection state and a holding state.

The method comprises the steps of completing initialization work of related structures, instances and callback functions in an initialization state, and initializing an MQTT sending thread corresponding to an MQTT sending module and an MQTT receiving thread corresponding to an MQTT receiving module, wherein the MQTT sending thread and the MQTT receiving thread are two threads which are independent of each other.

And completing the connection of the network connection and the MQTT protocol layer under the connection state, subscribing the required theme and starting a heartbeat cycle timer.

And switching to a response working mode driven by an input event in a holding state, and switching to a blocking state when no input event exists. Different input events are distinguished by different custom type headers and are classified and processed corresponding to three modules of 'keep sending', 'keep receiving' and 'error processing'. The maintaining transmission comprises related topic publishing, topic subscription, topic unsubscription and heartbeat request transmission of the MQTT protocol client. And keeping receiving response message receiving including various sending messages and subscribed topic data receiving. The error processing comprises the steps of response overtime processing of the server side, sending and receiving return error processing and sending failure condition feedback upper-layer application.

The input interface of the MQTT main processing module provided by the embodiment of the invention is realized by a message queue mechanism provided by an MQTT client operating system. And different event requests can be uniformly input to the MQTT main thread by multiple threads and multiple input sources, and queuing can be performed according to priority setting. And when the input message queue is empty, the MQTT main processing thread is blocked. The output interface of the MQTT main processing module is another message queue which is connected with the MQTT main processing thread and the MQTT sending thread to realize the MQTT data message sending requests of different events.

MQTT sending module: the function of transmitting the MQTT protocol message of different event requests in the MQTT main processing module is realized. And acquiring a message to be sent through an output interface of the MQTT main processing module, and calling a lower-layer network protocol stack interface to send the message. When the message is sent and returned to be wrong, injecting an error event through an input interface of the MQTT main processing module, and triggering the error processing action of the MQTT main processing module. When the output interface message queue of the MQTT main processing module is empty, the MQTT sending thread is blocked.

MQTT receiving module: and the function of receiving the protocol message transmitted to the MQTT protocol client by the MQTT server is realized. And calling a blocking receiving interface of a lower network protocol stack to obtain a message, injecting a message receiving event through an input interface of the MQTT main processing module, and triggering a message keeping receiving module of the MQTT main processing module to carry out subsequent processing on the message. When the message receives and returns an error, injecting an error event through an input interface of the MQTT main processing module, and triggering an error processing action of the MQTT main processing module; when there is no data to receive, the MQTT receive thread will also be blocked.

In addition, when the MQTT main processing module is initialized, a group of sending timers for message sending timing and a cycle timer for heartbeat triggering are initialized, and the timers are executed in software timer threads by utilizing a software timer mechanism provided by an operating system. Before the MQTT main thread is switched into a holding state from a connection state, a heartbeat trigger timer is started to trigger the arrival time of heartbeats according to preset heartbeat holding time. When heartbeat comes, the registered arrival time callback processing function during initialization checks whether a heartbeat response overtime condition occurs after a previous heartbeat request is sent. And if no overtime happens, injecting a heartbeat request event into the input message queue of the MQTT main processing module so as to trigger the main processing module to send a heartbeat request message. And if the heartbeat response timeout occurs, injecting a heartbeat timeout event into the input message queue, and triggering the error processing behavior of the main processing module.

In addition, when the MQTT sending module or the MQTT receiving module finishes sending or receiving a message once, the heartbeat trigger timer is reset. After each message needing to be responded by the opposite terminal is sent, a sending keeping module of the MQTT main processing module starts a sending timer, such as: topic publishing PUBLISH (QOS 1, 2), topic subscription SUBSCRIBE, UNSUBSCRIBE for subscribed topics, heartbeat request PINGRQ, PUBLISH received PUBREC. If receiving the corresponding message returned by the opposite terminal before the timer is overtime, clearing the corresponding timer, otherwise triggering a timer call-back processing function to generate a corresponding message response overtime event and injecting the message response overtime event into a main thread input message queue, thereby triggering the MQTT main processing module to perform error processing.

The MQTT main processing module needs to call an operating system thread to create and start an interface function to start as an independent thread. Optionally, the starting mode of the MQTT main thread may be implemented by outputting a shell interface function of the computer shell layer to a command line, for example: "mqtt _ start," or provide a user-level Application Programming Interface (API).

Inside the MQTT main thread, three STATEs of MQTT _ STATE _ INIT (initialization), "MQTT _ STATE _ CON" (connection) and "MQTT _ STATE _ KEEP" (maintenance) are divided, and the execution is judged by condition selection. When starting up the MQTT main thread, the STATE of 'MQTT _ STATE _ INIT' is preset to be entered first, namely, the initialization process is executed.

Next, referring to fig. 3, a flowchart of the MQTT main thread executing in the initialization state is shown. The flow chart comprises the following steps:

step 31: MQTT _ STATE _ INIT (initialization). In the initialization process, the thread will initialize.

Step 32: a network instance is initialized. Optionally, the network instance includes a server-side network address, a port number, a connection certificate, a callback function for network connection, disconnection, reading, and writing, and other information required for network connection.

Step 33: and initializing an MQTT protocol client instance. Optionally, the MQTT protocol client example includes: the client side message sending and receiving method comprises a sending buffer register buffer, a receiving buffer register buffer, a connection state indication and heartbeat state indication state bit, heartbeat interval time, an MQTT message Topic (Topic) filter structure, a sending timer, a heartbeat timer (optionally, the sending timer and the heartbeat timer are both software timers), and information required by the work of other MQTT protocol client sides.

Step 34: and initializing a subscription theme.

Step 35: and calling back a processing function for initialization when the subscription and the release fail. Optionally, the method includes initializing a topic, a service quality and a callback processing function of MQTT subscription, and performing a callback processing function of MQTT subscription failure and a callback processing function of MQTT release failure.

Step 36: initializing an input message queue and an output message queue. The MQTT main processing thread inputs and outputs a message queue: message queues are an inter-thread communication method provided by the underlying operating system, and variable-length data can be sent to a thread by multiple senders. In the invention, the blocking mode of the receiver is initialized, namely the thread which receives the message queue when the message queue is empty enters the blocking state. For the input message queue of the MQTT main processing thread, because there are multiple sources of data input, optionally, a prioritized message dequeuing method is implemented, that is, an "emergency event" such as a heartbeat request event or an error handling event is preferentially transmitted to the MQTT main thread for processing.

It should be noted that, a custom header of one byte may also be defined for different messages injected into the input message queue. Optionally, the custom message header includes a 4-bit "message type" field and a 4-bit "message ID" field. The message types are used for distinguishing different request events so as to trigger the MQTT main thread to be switched into different processing modules or different running states. The Message ID (MID) is used to distinguish and record different data packets that the upper user layer (e.g. application APP with MQTT protocol client) needs to send. When an error occurs in the transmission or the response is overtime, the MID informs the user of the data packet with the error, so that the user can conveniently initiate subsequent processing strategies such as data retransmission and the like.

For the situation of receiving the MQTT protocol message, a plurality of MQTT messages can be simultaneously sent to an input message queue to wait for MQTT main thread processing, but the total capacity of the message queue needs to be reasonably set according to a service model, so that the situation that the message queue is frequently full is prevented. For an output message queue of an MQTT main thread, messages to be sent for receiving different MQTT actions (such as topic subscription, topic unsubscription, topic publishing, publishing response and heartbeat request) are queued in the message queue, and a mode of receiver blocking is initialized, namely the output message queue is an empty MQTT sending thread.

Step 37: and initializing an MQTT sending thread and an MQTT receiving thread. The MQTT sending module and the MQTT receiving module are initialized into two independent threads through an operating system thread creating interface, and in the initialization state, the MQTT sending module and the MQTT receiving module are only initialized but not started.

Step 38: MQTT _ STATE _ CON. After the MQTT main processing thread finishes various initialization works, the STATE of the MQTT main processing thread is converted into an MQTT _ STATE _ CON connection STATE.

Referring next to fig. 4, a flow chart is executed for the MQTT send thread. In the flow chart, the following steps are included:

step 41: and outputting the message queue. There are messages in the output message queue that are input to the MQTT sending thread.

Step 42: output message queue message reception. The output message queue is a message source of the MQTT sending thread.

Step 43: the protocol stack sends the interface. And the MQTT sending thread sends the message in the output message queue to a lower protocol stack through a protocol stack sending interface.

Step 44: it is determined whether a message of failed delivery is returned. If yes, go to step 45, otherwise go to step 42.

Step 45: generating a send error event to the input message queue.

Step 46: a queue of messages is input. The MQTT main thread can obtain the information of the sending error event by inputting the message queue, so that the MQTT main thread can process the sending error event.

It should be noted that the MQTT sending module includes: (1) And the function is used for receiving the MQTT message to be sent. The MQTT message sending interface is a blocking interface, i.e. when the output message queue is empty, the MQTT sending thread will be blocked. (2) And the MQTT message sending function calls a sending interface function of a lower network protocol stack to send the message to be sent and the message length sequence. Optionally, the lower protocol stack may be a TCP/IP protocol stack interface or an AT protocol stack interface, and is configured according to a hardware module selected by the MQTT protocol client. (3) A "send error" handling function to handle the case where the network protocol stack returns a send error. When the message is sent to generate an error, the function generates a message with the message header type of 'sending error event', and calls a sending function of the input message queue of the main thread to inject the message into the input message queue so as to trigger the error processing action of the MQTT main processing thread.

Referring next to fig. 5, a flow chart is executed for the MQTT receiving thread. In the flow chart, the following steps are included:

step 51: the protocol stack receives the interface. The protocol stack receiving interface is used for receiving a message sent by a lower layer protocol stack, wherein the message is sent by a server.

Step 52: and judging whether the receiving fails or not. If yes, go to step 53, if no, go to step 55.

Step 53: generating a send error event to the input message queue.

Step 54: and generating a message receiving event to an input message queue.

Step 55: and inputting a message queue.

The MQTT main thread can obtain the information of the sending error event and the information of the message receiving event by inputting the message queue, so that the MQTT main thread can process the sending error event and the message receiving event.

It should be further noted that, the MQTT receiving module includes: and (1) receiving a function of the MQTT message. The function calls a receiving interface function of a lower protocol stack to receive the MQTT message from the network. Optionally, the lower layer protocol stack may be a TCP/IP protocol stack interface or an AT protocol stack interface. The receive interface function needs to be implemented as a blocking interface, i.e. the MQTT receive thread will be blocked when there is no data to receive. After receiving MQTT message, the thread will call the main thread to input the sending function of message queue, and generate and inject a self-defined message head as message receiving event message, so as to trigger MQTT main processing thread to transfer to the holding receiving module for processing. (2) And the function is used for processing the condition that the protocol stack returns a receiving error, generating a message with a message header type of a receiving error event when the message is received and generates an error, and calling a sending function of the input message queue of the MQTT main thread to inject the sending function into the input message queue so as to trigger the error processing action of the MQTT main thread.

Referring next to fig. 6, a flowchart is executed for MQTT main thread connection status. In this flowchart, the following steps are included:

step 61: MQTT _ STATE _ CON.

Step 62: and judging whether socket connection is established or not, if not, returning to the step 61, and if so, executing the step 63.

And step 63: and starting an MQTT sending thread and an MQTT receiving thread.

Step 64: a login token is generated.

Step 65: and generating a connection message.

And step 66: and sending the CONNECT message.

Step 67: it is determined whether a confirmation connection request CONNACK is returned within the timer, if not, step 68 is performed, and if so, step 69 is performed.

Step 68: it is determined whether an error code is returned, if so, go to step 610. If not, go to step 611, step 612, and re-go to step 61.

Step 610: and outputting an error prompt.

Step 611: and outputting a time-out prompt.

Step 612: the socket connection is disconnected.

Step 69: and generating a topic subscription SUBSCRIBE message.

Step 613: and sending the SUBSCRIBE message.

Step 614: and judging whether the SUBACK is returned within the timing. If not, go to step 615, if yes, go to step 616.

Step 615: and judging whether an error code is returned or not. If yes, go to step 617 and step 616. If not, go to step 618, step 619, and re-go to step 64.

Step 617: and (5) callback processing of subscription failure.

Step 618: and outputting the overtime reminding.

Step 619: and outputting a disconnected DISCONNECT message.

Step 616: a heartbeat timer is started.

Step 620: MQTT _ STATE _ KEEP.

The above steps will be explained in their entirety. Firstly, a client needs to establish socket network connection with a server, and a socket is established by calling a network instance callback function registered during initialization. Optionally, if the socket connection is not established successfully, the main thread will be reconnected in the loop.

Starting MQTT sending and receiving threads: and calling a thread starting function provided by an operating system, and transferring the initialized MQTT sending and receiving threads into a ready state.

It should be noted that, the MQTT client stores an MQTT client connection function, an MQTT topic subscription function, and a "heartbeat request" initiation function. The MQTT client connection function comprises the following steps: the protocol layer connection between the MQTT client and the server generally requires information such as "client ID", "client key", "client device name", "client device ID", and the like. Optionally, the information may be preset in an MQTT client structure, and the MQTT client needs to have an encrypted token generation function, so that the information is calculated through a certain encryption algorithm to obtain a token code required by logging in the server. Optionally, for simplicity and convenience in design, data transmission and data reception of the MQTT protocol client connection function are designed to be in a synchronous mode. After obtaining the login token, calling MQTT message framing function, combining the message header type to be transmitted, the service quality grade, the login token code and the like into a 'CONNECT' message according to the standard format of MQTT protocol, and storing the message in a transmission cache region. And then, calling a sending interface of the output message queue to send the message to the MQTT sending thread. Then the MQTT main thread waits for the data condition returned by the MQTT receiving thread at fixed time, namely, the receiving interface of the input message queue is called. Since the interface is initialized to be a blocking interface before, the blocking time at this time needs to be set as a waiting time. After the timing expires, there may be three results: (1) The receiving interface of the input message queue has data return, an MQTT message decoding function is called to obtain a server-side returned connection success confirmation 'CONNACK', at the moment, an MQTT main thread sets a connection indication state position of a client-side instance, and then a subsequent MQTT theme subscription process is executed; (2) The receiving interface of the input message queue has CONNACK return, calls MQTT data frame decoding function, and obtains the reject connection or other error codes returned by the server, such as: the user ID is wrong, the user token is wrong, the user authorization is overdue and the like, and at the moment, the MQTT main thread prompts and suspends printing related errors; (3) And (3) no data is returned from a receiving interface of the input message queue, the MQTT main thread outputs relevant overtime errors to be printed, calls a callback function of the disconnection of the network instance to disconnect the socket connection, and then returns to the starting statement of the MQTT _ STATE _ CON STATE to restart execution.

MQTT topic subscription function: similar to the MQTT protocol client connection process, the main processing thread calls a message framing function organization 'SUBSCRIBE' message according to a preset Topic filter Topic (Topic) in an initialized client instance structure and sends the message through an output message queue. The same waiting on the receive interface timing of the incoming message queue still has three possible results: (1) The MQTT receiving thread returns a SUBACK type message to indicate that subscription is successful, and at the moment, the MQTT main thread outputs related printing information and continues to execute subsequent processes; (2) The MQTT receiving thread returns a SUBACK message, but a corresponding error code obtained by decoding indicates 'subscription failure', and at the moment, the MQTT main processing thread outputs related printing information and calls an initialized MQTT subscription failure callback processing function to notify failure information to upper-layer user application; (3) If no data is returned after the timing is up, optionally, the MQTT main thread outputs related error printing, calls an MQTT client-side disconnection function, sends a "DISCONNECT" type message to the server side, then returns to an initial statement of an MQTT _ STATE _ CON STATE to restart execution, and skips the socket connection step and the sending and receiving thread starting steps due to the fact that the network socket connection STATE bit is still 1 and the MQTT sending and receiving threads are started during the execution.

The "heartbeat request" initiates the function: when the main thread finishes theme subscription, a client end heartbeat keeping timer is started, the heartbeat timer is initialized in the initialization process, a cycle timer is set according to the heartbeat interval time preset by the client end instance, and the timer is reset after the sending or receiving thread finishes sending or receiving messages every time.

After the MQTT client finishes connecting with the protocol layer of the server, the main processing thread transfers the STATE of the MQTT client to the 'MQTT _ STATE _ KEEP', namely the 'STATE keeping' STATE.

Referring next to fig. 7a, fig. 7b, and fig. 7c, a flow chart of MQTT main thread hold state execution according to an embodiment of the present invention is provided.

In fig. 7a, the following steps are included:

step 71a: MQTT _ STATE _ KEEP.

Step 72a: input message queue message reception.

Step 73a: and (5) self-defining message header analysis.

Step 74a: the reception is maintained.

Step 75a: and analyzing the message.

Step 76a: and judging whether the message is an allowable type message. If not, step 77a is performed, and if so, step 78a is performed.

Step 77a: and discarding the message. And step 72a is re-executed.

Step 78a: and judging whether an opposite end response message exists, if so, executing one step or a plurality of

steps

79a, 710a or 711a, and if not, executing one step or a plurality of

steps

721a or 722 a.

Step 79a: and judging that the opposite end message is the PUBREC message, and executing the step 712a and the step 713a.

Step 712a: the PID is reset to the timer.

Step 713a: and generating a PUBREL message and sending the PUBREL message to an output message queue. And step 72a is performed again.

Step 710a: and judging that the message at the opposite end is a PINGRSP message, and executing the step 714a.

Step 714a: the heartbeat sent bit is cleared. And step 72a is re-executed.

Step 711a: and judging that the opposite end message is other response messages, and executing step 715a.

Step 715a: and closing the PID corresponding timer.

Step 716a: it is determined whether an error code is returned, if yes, step 717a is performed, and if not, step 719a is performed.

Step 717a: the recorded PID and MID are cleared.

Step 718a: and returning an error code and an MID number to the user layer. And step 72a is re-executed.

Step 719a: the recorded PID and MID are cleared.

Step 720a: and returning the MID number which is successfully sent to the user layer.

Step 721a: if the packet is determined to be a PUBLISH packet, step 723a is executed.

Step 723a: and judging whether the message is a QOS2 message, if so, executing a step 724a, and if not, executing a step 726a.

Step 724a: and generating a PUBREC message and sending the PUBREC message to an output message queue.

Step 725a: a transmit timer is started and the PID is recorded. And step 72a is re-executed.

Step 726a: and generating a PUSCK message and sending the PUSCK message to an output message queue. And step 72a is re-executed.

Step 722a: and judging the message as a PUBREL message. Step 727a is performed.

Step 727a: and closing the PID corresponding timer.

Step 728a: and generating a PUBCOMP message and sending the message to an output message queue. And step 72a is re-executed.

Referring next to fig. 7b, the following steps are included:

step 71b: MQTT _ STATE _ KEEP.

Step 72b: an incoming message queue message receives.

Step 73b: and (5) self-defining message header analysis.

Step 74b: and keeping sending.

Step 75b: it is determined whether a heartbeat request event exists. If not, step 77b is performed, and if so, step 76b is performed.

Step 77b: and generating a publishing, subscribing or unsubscribing message.

Step 78b: and sending the message to an output message queue.

Step 79b: a transmit timer is started and the PID and MID are recorded. And performs step 710b and re-performs step 72b.

Step 76b: and generating a PINGRQ message.

Step 712b: and sending the message to an output message queue.

Step 713b: setting the heartbeat request has sent a status bit. And performs step 714b and re-performs step 72b.

Step 710b: it is determined whether the transmission timer has timed out, if yes, step 711b is executed, and if no, step 72b is executed.

Step 711b: a send timeout event is generated to the input message queue and injected into the PID and MID.

Step 714b: and judging whether the heartbeat timer has a heartbeat request set at the time, if so, executing the step 715b, and if not, executing the step 716b.

Step 715b: a heartbeat timeout event is generated to the input message queue.

Step 716b: generates a heartbeat request event to the input message queue and re-executes step 72b.

Referring next to fig. 7c, the following steps are included:

step 71c: MQTT _ STATE _ KEEP.

Step 72c: an incoming message queue message receives.

Step 73c: and (5) self-defining message header analysis.

Step 74c: and (5) error processing.

Step 75c: and judging whether the overtime errors of publishing, subscribing and unsubscribing exist. If yes, go to step 76c, otherwise go to step 77c.

Step 76c: and recording the overtime message MID.

Step 78c: closing and emptying the input and output message queues.

Step 79c: and clearing the subscribed topics and clearing the relevant information of the client.

Step 710c: and disconnecting the socket network connection.

Step 711c: and returning the incomplete MID number and error information to the user layer.

Step 712c: MQTT _ STATE _ CON.

Step 77c: a determination is made as to whether the traversal send record and input message queue can obtain an MID, if so, step 76c is performed, and if not, step 78c is performed.

Next, fig. 7a to 7c will be further described. In the holding state, the method comprises the following steps and modules:

output interface of input message queue: the interface is implemented in a blocking manner, and when an input message queue is empty, an MQTT main processing thread enters blocking.

Self-defining a message header parsing function: since "messages" (data) in a message queue correspond to a variety of possible "events," a 1byte message type and message ID field (MID) is customized in each message header. Optionally, the message types include: the field occupies the low 4 bits of the custom message header. The Message ID (MID) only aims at the events of publishing, subscribing and unsubscribing issued by the upper layer user layer to distinguish, and occupies 4 bits higher than the custom message header. That is, the client input message queue can simultaneously accommodate up to 16 messages to be sent by the user layer (excluding other messages). After the message type is analyzed by the message header analysis function, different processing modules are switched to process the message type through condition selection.

The MQTT protocol client keeps the send function: the events needing to be processed by the function are MQTT topic publishing events, MQTT topic subscribing events, MQTT topic unsubscribing events and heartbeat request events. For MQTT topic publishing, the event is optionally entered into the message queue by the user application, or may be supported by the shell command input at the same time. When the type of the input message queue message is 'release event', the function is switched to process; calling a message framing function to organize received data to be published into a 'PUBLISH' message according to the requirement of the MQTT protocol message format and storing the 'PUBLISH' message into a sending cache region of a client instance; calling an output message queue input interface to send the message in the sending buffer area to an output message queue; for the PUBLISH message of the quality of service QOS0, no response needs to be returned by the server, and for the messages of QOS1 and QOS2, responses need to be returned. Optionally, the upper layer application is implemented in an asynchronous IO mode, and after each QOS1 and QOS2 level Packet is sent to the message queue, a sending timer is started, where the timer is initialized in the initialization process, and records a Packet Identifier (PID) of the Packet and a user application custom message ID number (MID). If the server end returns the "PUBACK" message (for QOS 1) or the "PUBREC" message (for QOS 2) before the timer is up, the related recording information is closed and cleared or the sending timer is delayed (for the PUBREC message). If the timer is out of time and no message is returned, calling the overtime callback function to send a 'sending overtime event' to the input message queue, injecting PID and MID, and transferring the main processing thread to an error processing module for processing.

Specifically, when the heartbeat timer expires, a "heartbeat request event" is generated and injected into the MQTT main thread input message queue, and the MQTT main thread treats it as a special "issue event" in the hold send function: and calling a framing function to generate a PINGRQ message according to a protocol format, and sending the PINGRQ message to an output message queue. Setting a heartbeat indication state bit to indicate that the heartbeat request is sent, and clearing the heartbeat request sent bit if the server end returns a PINGRSP heartbeat request response message before the next heartbeat timer expires. Otherwise, calling the timeout callback function to send a heartbeat timeout event to the input message queue, and transferring the MQTT main thread to an error processing module for processing.

Specifically, when the client needs to re-subscribe or unsubscribe to the topic, the MQTT main thread will also treat it as a special "publish event" in the hold-send function: optionally, the subscription and unsubscribe actions are supported for being input into the message queue by the user application program or being input by the shell command. Calling a message framing function to generate a SUBSCRIBE or UNSUBSCRIBE message and sending the message to an output message queue; and simultaneously starting a corresponding sending timer and recording the message identifier PID and the user-defined MID number. If the server end returns the corresponding SUBACK or UNSUBACK message before the timer arrives, the timer and the related recording information are cleared, otherwise, an overtime callback function is called to send a 'subscription (/ unsubscribe) error event' to the input message queue, PID and MID are injected, and the main processing thread is transferred to an error processing module for processing.

The MQTT protocol client keeps receiving functions: when receiving an MQTT message coming from the network, an MQTT receiving thread generates a message head of a message receiving event to synthesize a receiving message and sends the message head to an input message queue; when the message header analysis function finds that the message header type is a receiving event by identifying the message header type, the message header analysis function is switched to the function for processing. And calling a message decoding function to decode the received message into related data according to the requirement of the message format of the MQTT protocol and store the data into a receiving cache region of the client instance. Here, the types of messages that may be received to maintain the receive function are: theme publishing PUBLISH, publishing confirmation PUBACK, publishing received PUBREC, publishing released PUBREL, publishing completed PUBCOMP, heartbeat response PINGRSP, message subscription response SUBACK and unsubscribing confirmation UNSUBACK, and discarding the messages of which the types are not the above as illegal messages, wherein the steps are as follows: for a PUBLISH type message: and comparing the Topic (Topic) with the Topic filter (Topic _ filter) Topic defined by initialization, and calling the corresponding Topic subscription callback function defined by initialization to process if the Topic conforms to the Topic filter Topic. And then, calling a message framing function to generate a PUBACK type (for QOS 1), if the PUBLISH message is of a QOS2 grade, generating a PUBREC type message and sending the PUBREC type message to an output message queue, and simultaneously starting a sending timer and recording a message identifier PID (proportion integration differentiation) so as to judge that a subsequent PUBREL message is received.

For the PUSCK type message: and closing a sending timer corresponding to the PID of the message identifier, and clearing the recorded PID and MID numbers. Optionally, in the case that the upper layer application needs to implement synchronous communication, a "response success" callback processing function may be registered in advance, and the MID number is returned to the upper layer application before the corresponding PID and MID are cleared.

For the PUBREC type message: and resetting a sending timer corresponding to the message identifier PID, calling a message framing function to generate a PUBREL type message, and sending the PUBREL type message to an output message queue.

For the PUBREL type message: closing a sending timer corresponding to the message identifier PID (the timer is started when the PUBREC message is sent previously), clearing the recorded PID number, calling a message framing function to generate a PUBCOMP type message, and sending the PUBCOMP type message to an output message queue.

For the PUBCOMP type message: closing a sending timer corresponding to the PID of the message identifier, and clearing the recorded PID and MID numbers; optionally, in the case that the upper layer application needs to implement synchronous communication, a "response success" callback processing function may be registered in advance, and the MID number is returned to the upper layer application before the corresponding PID and MID are cleared.

For a PINGRESP type message: the client global heartbeat request sent status bit is cleared.

For the SUBACK type message: the message contains a return code which may indicate 'successful subscription' or 'failed subscription', the sending timer corresponding to the message identifier PID is closed, and the recorded PID and MID numbers are cleared. Optionally, the "response success" callback processing function is registered in advance, and the return code and the MID number are returned to the upper layer application before the corresponding PID and MID are cleared.

For UNSUBACK type messages: the message contains a return code which may indicate 'unsubscription success' or 'unsubscription failure', the sending timer corresponding to the message identifier PID is closed, and the recorded PID and MID numbers are cleared. Optionally, the "response success" callback processing function is registered in advance, and the return code and the MID number are returned to the upper layer application before the corresponding PID and MID are cleared.

In the above message processing flows, if the timer expires without message return, the timer thread will automatically call the timeout callback function to send a relevant type of "error event" and "error code" to the input message queue. Optionally, the error events may be queued in the message queue according to priority, that is, the message queue preferentially outputs the "error event", and the main processing thread is transferred to the error processing module for processing after receiving the "error event".

Error handling function: the error event is divided into two categories of sending and receiving thread call return error and server end response timeout. Optionally, in order to simplify the design, the client is reset uniformly for both of the two major types of errors, and the upper layer user application is notified, and the user application layer processes the message retransmission policy by itself. The execution flow is as follows, firstly, a timer closing function is called to close all current timing timers, for the condition that the message is PUBLISH, SUBSCRIBE or UNSUBSCRIBE in response overtime, the MQTT main thread keeps the sending module to record the MID number corresponding to the message, and at the moment, the error processing function queries the MID number. For other errors, the error handling function will sequentially traverse the recorded sending timer and the corresponding MID, if no MID number is found, traverse the MID numbers in all message headers in the input message queue, and obtain the first found MID number (or not obtain any MID number). Then, a message queue closing function is called, the current main thread input and output message queues are emptied and closed, the subscribed MQTT message subjects are cleared, the connection and heartbeat indication status bit of the client entity is cleared, and the disconnection callback function of the network instance is called to disconnect the socket connection. And finally, calling an error processing callback function registered by the upper layer user application, notifying the related error information and the MID number of an uncompleted event when an error occurs, setting the STATE of the main thread to MQTT _ STATE _ CON, and executing the connection flow again.

Next, see fig. 8. Based on the same technical concept as the information processing method described above, another embodiment of the present invention provides an information processing apparatus, which achieves similar effects to those achieved by the above method and is not described herein again.

The information processing apparatus provided by the embodiment of the present invention includes: a determining module 81 for determining that there is no input information corresponding to a first thread of a message queue telemetry transport MQTT protocol client;

the control module 82 is configured to control the first thread to enter a blocking state, and release a processor time slice occupied by the first thread;

the control module 82 is further configured to execute other threads than the first thread using the released processor time slice.

In the information processing apparatus provided in the embodiment of the present invention, when the first thread is a main thread, the input information is information in an input message queue; when the first thread is a sending thread, the input message is information in an output message queue; when the first thread is a receiving thread, the input message is a message sent by a server; wherein the input message queue includes information input to the main thread, and the output message queue includes information processed by the main thread and input to the sending thread.

In the information processing apparatus according to the embodiment of the present invention, the control module 82, after controlling the first thread to enter the blocking state, is further configured to: and when input information of a first thread corresponding to the MQTT protocol client side is monitored, controlling the first thread to be updated from the blocking state to the awakening state.

In the information processing apparatus provided in the embodiment of the present invention, the control module 82 is further configured to: and communicating with the server in an asynchronous communication mode.

In the information processing apparatus according to the embodiment of the present invention, the control module 82 is specifically configured to, when the asynchronous communication mode is used for communicating with the server: the method comprises the steps of sending first data information to a server through a sending thread, and receiving second data information fed back by the server through a receiving thread, wherein the sending thread and the receiving thread adopt an asynchronous working mode.

In the information processing apparatus provided in the embodiment of the present invention, the determining module 81 is further configured to: determining a target communication mode according to the target parameters; the target communication mode is used for communicating with a server, and the target communication mode is a synchronous communication mode or an asynchronous communication mode.

Yet another embodiment of the present invention provides an electronic apparatus including: the processor, the memory and the program stored in the memory and capable of running on the processor, wherein the program, when executed by the processor, implements the information processing method as described above and can achieve the same technical effects, and the details are not repeated here to avoid repetition.

Another preferred embodiment of the present invention further provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the steps of the information processing method described above are implemented, and the same technical effects can be achieved, and are not described herein again to avoid repetition.

Furthermore, the present invention may repeat reference numerals and/or letters in the various examples. This repetition is for the purpose of simplicity and clarity and does not in itself dictate a relationship between the various embodiments and/or configurations discussed.

It is further noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion.

While the foregoing is directed to the preferred embodiment of the present invention, it will be understood by those skilled in the art that various changes and modifications may be made without departing from the spirit and scope of the invention as defined in the appended claims.

Claims

1. An information processing method, characterized in that the method comprises:

under the condition that input information of a first thread corresponding to a message queue telemetry transmission MQTT protocol client does not exist, controlling the first thread to enter a blocking state, and releasing a processor time slice occupied by the first thread;

executing other threads than the first thread using the released processor time slice.

2. The information processing method according to claim 1, wherein when the first thread is a main thread, the input information is information in an input message queue;

when the first thread is a sending thread, the input message is information in an output message queue;

when the first thread is a receiving thread, the input message is a message sent by a server;

wherein the input message queue includes information input to the main thread, and the output message queue includes information processed by the main thread and input to the sending thread.

3. The information processing method according to claim 1, further comprising, after controlling the first thread to enter a blocking state:

and when input information of a first thread corresponding to the MQTT protocol client side is monitored, controlling the first thread to be updated from the blocking state to the awakening state.

4. The information processing method according to claim 1, characterized by further comprising:

and communicating with the server in an asynchronous communication mode.

5. The information processing method according to claim 4, wherein the communicating with the server in an asynchronous communication manner includes:

the method comprises the steps of sending first data information to a server through a sending thread, and receiving second data information fed back by the server through a receiving thread, wherein the sending thread and the receiving thread adopt an asynchronous working mode.

6. The information processing method according to claim 1, characterized by further comprising:

determining a target communication mode according to the target parameters;

the target communication mode is used for communicating with a server, and the target communication mode is a synchronous communication mode or an asynchronous communication mode.

7. An information processing apparatus characterized in that the apparatus comprises:

the determining module is used for determining that input information of a first thread corresponding to the client of the message queue telemetry transmission MQTT protocol does not exist;

the control module is used for controlling the first thread to enter a blocking state and releasing a processor time slice occupied by the first thread;

and the control module is also used for executing other threads except the first thread by utilizing the released processor time slices.

8. The information processing apparatus according to claim 7, wherein when the first thread is a main thread, the input information is information in an input message queue;

9. An electronic device, comprising: processor, memory and program stored on the memory and executable on the processor, which when executed by the processor implements the information processing method according to any one of claims 1 to 6.

10. A computer-readable storage medium, on which a computer program is stored which, when executed by a processor, carries out the steps of the information processing method according to any one of claims 1 to 6.