Equipment message management method and device, electronic equipment and storage medium

Abstract

The invention provides an equipment message management method and device, electronic equipment and a storage medium, and the method comprises the steps: a state machine engine creates a target transaction for a target message of equipment, and sets the state of the target transaction as a first state; when the release event for the target message exists, modifying the state of the target transaction into a second state; when a first cancel event for the target message exists, modifying the state of the target transaction into a third state, and triggering cancel of release of the target message for the equipment; and when a release confirmation event for the target message exists, modifying the state of the target transaction into a fourth state, and triggering release of the target message for the equipment. According to the embodiment of the invention, the problems of false alarm, state oscillation, resource waste and the like can be avoided.

Description

Methods, apparatuses, electronic devices and storage media for managing device messages Technical Field

[0001] This application belongs to the technical field of message publishing, and specifically relates to a method, apparatus, electronic device, and storage medium for managing device messages. Background Technology

[0002] In related technologies, devices and servers may experience disconnections due to network fluctuations or other factors. After the disconnection, the server will issue a message indicating that the device is online. Since the disconnection is only caused by network fluctuations, the device may reconnect to the server shortly afterward, causing the server to then issue another "online" status message for the device. This can lead to maintenance personnel receiving interfering messages, reducing the reliability of device monitoring, and potentially causing business logic confusion and additional processing overhead. Summary of the Invention

[0003] In view of the above problems, a device message management method, apparatus, electronic device, and storage medium are proposed to overcome or at least partially solve the above problems, comprising: a device message management method applied to a state machine engine, the method comprising: the state machine engine creating a target transaction for a target message of the device and setting the state of the target transaction to a first state; when a publish event for the target message exists, modifying the state of the target transaction to a second state; when a first cancellation event for the target message exists, modifying the state of the target transaction to a third state and triggering the cancellation of the publish of the target message for the device; when a confirmation publish event for the target message exists, modifying the state of the target transaction to a fourth state and triggering the publish of the target message for the device.

[0004] In some embodiments, the state machine engine is deployed on a server, and the method further includes: responding to a state query request from the server, returning the second state of the target transaction to the server; the state query request is a request generated by the server when it detects a second cancellation event for the target message; when a cancellation request is received from the server in response to the second state, it is determined that a first cancellation event exists for the target message.

[0005] In some embodiments, the state machine engine is deployed on a server, and triggering the cancellation of the publication of the target message for the device includes: sending a first instruction to the server to discard the target message; the server discarding the target message in response to the first instruction; and triggering the server to confirm the connection with the device.

[0006] In some embodiments, the state machine engine is deployed on a server, and triggering the publication of the target message for the device includes: sending a second instruction to the server to publish the target message; the server responding to the second instruction to publish the target message.

[0007] In some embodiments, when modifying the state of the target transaction to a second state, the method further includes: initiating a delay timer for the target transaction.

[0008] In some embodiments, the method further includes: detecting whether the delay timer has timed out; when the delay timer has timed out, determining that there is an acknowledgment release event for the target message.

[0009] This application embodiment also provides a device message management method applied to a server, wherein a state machine engine is deployed in the server; the method includes: the server registering a target message, triggering the state machine engine to create a target transaction for the target message, and triggering the state machine engine to set the state of the target transaction to a first state; when a device triggers a publish event for the target message, triggering the state machine engine to modify the state of the target transaction to a second state; when a second cancellation event for the target message is detected, sending a state query request to the state machine engine; the state machine engine responding to the server's state query request by returning the second state of the target transaction to the server; responding to the second state by returning a cancellation request to the state machine engine; the state machine engine responding to the cancellation request by determining that a first cancellation event for the target message exists, and modifying the state of the target transaction to a third state; when the state of the target transaction is the third state, canceling the publish of the target message for the device; and when the state of the target transaction is a fourth state, publishing the target message.

[0010] In some embodiments, the target message is a will message, and the step of sending a status query request to the state machine engine when a second cancellation event for the target message is detected includes: reconnecting with the device; when the device successfully reconnects with the server, determining that a second cancellation event for the target message has been detected; and sending the status query request to the state machine engine.

[0011] This application embodiment also provides a device message management apparatus applied to a state machine engine. The apparatus includes: a setting module, used by the state machine engine to create a target transaction for a target message of the device, and set the state of the target transaction to a first state; a first modification module, used to modify the state of the target transaction to a second state when a publish event for the target message exists; a second modification module, used to modify the state of the target transaction to a third state and trigger the cancellation of the publish of the target message for the device when a first cancellation event for the target message exists; and a third modification module, used to modify the state of the target transaction to a fourth state and trigger the publish of the target message for the device when a confirm publish event for the target message exists.

[0012] This application embodiment also provides a device message management apparatus applied to a server, wherein a state machine engine is deployed in the server; the apparatus includes: a first triggering module, used for the server to register a target message, triggering the state machine engine to create a target transaction for the target message, and triggering the state machine engine to set the state of the target transaction to a first state; a second triggering module, used for triggering the state machine engine to modify the state of the target transaction to a second state when a device triggers a publish event for the target message; and a first request module, used for requesting the state machine engine when a second cancellation event for the target message is detected. The state machine engine sends a status query request; in response to the status query request from the server, the state machine engine returns the second status of the target transaction to the server; the second request module returns a cancellation request to the state machine engine in response to the second status; in response to the cancellation request, the state machine engine determines that there is a first cancellation event for the target message and modifies the status of the target transaction to the third status; the cancellation module cancels the publication of the target message for the device when the status of the target transaction is the third status; the publication module publishes the target message when the status of the target transaction is the fourth status.

[0013] This application also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, it implements the device message management method described above.

[0014] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the above-described device message management method.

[0015] The embodiments of this application have the following advantages: In these embodiments, the state machine engine creates a target transaction for a target message of a device and sets the state of the target transaction to a first state; when a publish event for the target message occurs, the state of the target transaction is modified to a second state; when a first cancellation event for the target message occurs, the state of the target transaction is modified to a third state, and the publication of the target message for the device is cancelled; when a confirmation publish event for the target message occurs, the state of the target transaction is modified to a fourth state, and the publication of the target message for the device is triggered. Through these embodiments, problems such as false alarms, state fluctuations, and resource waste can be avoided. Attached Figure Description

[0016] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments in conjunction with the following drawings, in which: FIG1 is a flowchart of the steps of a device message management method according to an embodiment of this application; FIG2 is a flowchart of the steps of another device message management method according to an embodiment of this application; FIG3 is a flowchart of the steps of yet another device message management method according to an embodiment of this application; FIG4 is a schematic diagram of data interaction according to an embodiment of this application; FIG5 is a schematic diagram of the structure of a device message management device according to an embodiment of this application; FIG6 is a schematic diagram of the structure of another device message management device according to an embodiment of this application. Detailed Implementation

[0017] To make the above-mentioned objectives, features, and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0018] In the relevant MQTT (Message Queuing Telemetry Transport) protocol, brief network fluctuations (such as Wi-Fi roaming, cellular network switching, signal interference) may cause a momentary interruption of the TCP (Transmission Control Protocol) connection between the device and the server (Broker), which may lead to the immediate and false triggering of will messages. This may cause the following problems: false alarms: the system receives incorrect device "offline" alarms, causing maintenance personnel to receive interfering information and reducing the reliability of the monitoring system.

[0019] Status oscillation: Subscribers first receive a will message ("offline"), and then receive an "online" status message after the device reconnects, causing business logic confusion and additional processing overhead.

[0020] Resource waste: The system's backend services need to handle these unnecessary state change events, consuming computing, storage, and network resources.

[0021] The root of these problems lies in the fact that the standard MQTT protocol stipulates that once the Broker detects an abnormal closure of the connection, it must immediately issue a will message, lacking fault tolerance for momentary disconnections.

[0022] To address the problems existing in related technologies, this application provides a device message management method. By encapsulating message triggers into a transaction object and managing the state of the transaction object, the method performs a publish operation under different states, thereby avoiding noise caused by network interruptions.

[0023] Referring to FIG1, a flowchart of a device message management method according to an embodiment of the present application is shown, which may include the following steps: Step 101: The state machine engine creates a target transaction for the target message of the device and sets the state of the target transaction to a first state.

[0024] In this application embodiment, the state machine engine can refer to a reusable component / service that encapsulates the core logic of a finite state machine (FSM). It provides standardized state definition, event handling, and state transition rule management capabilities, and can be used independently or embedded in other systems to handle complex state-driven business processes.

[0025] In some embodiments, the state machine engine can be deployed on a server connected to the device. After the device establishes a connection with the server, the server can create a session with the state machine engine and register target messages. Target messages can be messages that the server will publish to the device, such as will messages or service instance deregistration messages.

[0026] In MQTT, the will message is an abnormal offline notification mechanism. It means that when a device establishes a connection, it pre-sets a message. If the device disconnects from the server due to abnormal circumstances such as network interruption or device failure (without sending a DISCONNECT normal disconnect command), the MQTT server will automatically send this pre-set message to the designated subscriber.

[0027] After registering the target message, the state machine engine creates a target transaction for the target message on the device. A transaction is an execution unit that guarantees the atomicity, consistency, isolation, and durability of a set of operations. Its core purpose is to avoid data inconsistencies or logical breaks when the state machine handles state transitions and business actions. This target transaction can be a transaction for the target message and can have states, such as: first state, second state, second state, and third state.

[0028] For example, if the target message is a will message, the first state can be a standby state, that is, the device and the server are connected normally, the target transaction exists but is dormant; the second state can be a soft offline state, that is, the device and the server are lost; the third state can be a cancelled state, that is, in the second state, the device and the server successfully reconnected and the will message was cancelled; the fourth state can be a final offline state, that is, the timeout did not reconnect and the will message was published.

[0029] After creating the target transaction, you can first set the current state of the target transaction to the first state; for example, the first state can refer to the state of the target transaction before the target message is triggered.

[0030] Step 102: When there is a publish event for the target message, change the state of the target transaction to the second state.

[0031] In some embodiments, a publishing event can be defined, which can be defined based on the publishing conditions of the target message; for example, if the target message is a will message, the event of the device losing connection with the server can be defined as a publishing event.

[0032] In this embodiment of the application, the state machine engine can detect whether there is a publication event for the target message; if so, the state of the target transaction can be modified from the first state to the second state.

[0033] Before modifying the state, you can first check if the target transaction is in the first state; if the target transaction is detected to be in the first state, you can then execute the step of changing the target transaction's state from the first state to the second state.

[0034] Conversely, if the target transaction is detected to be in a state other than the first state, it means that it has been preempted by another process; in this case, the step of changing the target transaction's state from the first state to the second state can be skipped.

[0035] For example, if the target message is a will message, and a disconnection between the device and the server is detected, the state machine engine can change the target transaction from the first state to the second state; that is, from the standby state to the soft offline state. In this case, if the server detects that the target transaction is in the second state, it will not execute the operation to publish the will message.

[0036] Step 103: When a first cancellation event occurs for the target message, change the state of the target transaction to the third state and trigger the cancellation of the publication of the target message for the device.

[0037] In this embodiment of the application, after the state machine engine modifies the state of the target transaction from the first state to the second state, it can detect whether there is a first cancellation event for the target message; the first cancellation event may refer to the event initiating by the server to cancel the publication of the target message, and the first cancellation event can be set according to the actual situation; for example, the first cancellation event may refer to the event in which the server requests the state machine engine to cancel the handshake.

[0038] After detecting the existence of a first cancellation event for the target message, the state machine engine can change the state of the target transaction from the second state to the third state; specifically, before making the change, the state machine engine can first check whether the current state of the target transaction is the second state.

[0039] If the target transaction is currently in the second state, the state machine engine can execute the step of changing the target transaction's state to the third state; conversely, if the target transaction is not currently in the second state, it means that it has been preempted by another process; in this case, the step of changing the target transaction's state from the second state to the third state can be skipped.

[0040] After the state machine engine changes the state of the target transaction from the second state to the third state, it can trigger the cancellation of the publication of the target message for the device. Specifically, the state machine engine can trigger the server to cancel the publication of the target message to avoid problems such as false alarms, state fluctuations, and resource waste.

[0041] Step 104: When there is a confirmation release event for the target message, change the state of the target transaction to the fourth state and trigger the release of the target message for the device.

[0042] In some embodiments, after changing the state of the target transaction from the first state to the second state, it is also possible to detect whether there is a confirmation release event for the target message; the confirmation release event may refer to an event confirming that the target message needs to be released, and the confirmation release event can be set according to the actual situation; for example, the confirmation release event may refer to an event in which the device and the server are not detected to have successfully reconnected within a timeout period.

[0043] After detecting the existence of an acknowledgment publication event for the target message, the state machine engine can change the state of the target transaction from the second state to the fourth state; specifically, before making the change, the state machine engine can first check whether the current state of the target transaction is the second state.

[0044] If the target transaction is currently in state two, the state machine engine can execute the step of changing the target transaction's state to state four. Conversely, if the target transaction is not currently in state two, it means that it has been preempted by another process. In this case, the step of changing the target transaction's state from state two to state four does not need to be executed.

[0045] After the state machine engine changes the state of the target transaction from the second state to the fourth state, it can trigger the publication of the target message for the device; specifically, the state machine engine can trigger the server to publish the target message to send the target message to the subscribers.

[0046] In this embodiment, the state machine engine creates a target transaction for a target message from a device and sets the target transaction's state to a first state. When a publish event for the target message occurs, the state of the target transaction is changed to a second state. When a first cancellation event for the target message occurs, the state of the target transaction is changed to a third state, and the publication of the target message for the device is cancelled. When a confirm publish event for the target message occurs, the state of the target transaction is changed to a fourth state, and the publication of the target message for the device is triggered. This embodiment avoids problems such as false alarms, state fluctuations, and resource waste.

[0047] Referring to FIG2, a flowchart of another device message management method according to an embodiment of the present application is shown, which may include the following steps: Step 201: The state machine engine creates a target transaction for the target message of the device and sets the state of the target transaction to a first state.

[0048] In some embodiments, the state machine engine can be deployed on a server connected to the device. After the device establishes a connection with the server, the server can create a session with the state machine engine and register target messages. Target messages can be messages that the server will publish to the device, such as will messages or service instance deregistration messages.

[0049] After registering the target message, the state machine engine creates a target transaction for the target message of the device.

[0050] After creating the target transaction, the state machine engine can first set the current state of the target transaction to the first state.

[0051] Step 202: When there is a publish event for the target message, change the state of the target transaction to the second state.

[0052] In some embodiments, the state machine engine can detect whether there is a publish event for the target message; if so, the state of the target transaction can be changed from the first state to the second state.

[0053] Before modifying the state, you can first check if the target transaction is in the first state; if the target transaction is detected to be in the first state, you can then execute the step of changing the target transaction's state from the first state to the second state.

[0054] Conversely, if the target transaction is detected to be in a state other than the first state, it means that it has been preempted by another process; in this case, the step of changing the target transaction's state from the first state to the second state can be skipped.

[0055] In some embodiments of this application, when the state of the target transaction is modified to the second state, the above method may further include the following step: starting a delay timer for the target transaction.

[0056] In some embodiments, when the state machine engine modifies the state of the target transaction from the first state to the second state, it can also start a delay timer for the target transaction to detect whether the reconnection between the server and the device has timed out.

[0057] In some embodiments of this application, based on the delay timer, the following steps may also be included: detecting whether the delay timer has timed out; when the delay timer has timed out, determining that there is an acknowledgment release event for the target message.

[0058] In some embodiments, it can be detected whether the delay time exceeds a preset duration; if the delay time exceeds the preset duration and the device and the server have not yet successfully reconnected, it can be determined that the target message does need to be published; at this time, it can be determined that there is a confirmation publication event for the target message.

[0059] Conversely, if the delay timer is not detected to have exceeded the preset duration, and the device and server have not yet successfully reconnected, the delay timer can continue to be checked until it expires or the device and server are successfully reconnected if it has not expired.

[0060] Step 203: In response to the server's status query request, return the second status of the target transaction to the server; the status query request is a request generated by the server when it detects the second cancellation event for the target message.

[0061] In some embodiments, the state machine engine can be deployed on a server connected to the device. When the server detects a second cancellation event, it can generate a state query request and send the request to the state machine engine.

[0062] The second cancellation event can be set according to the actual situation; for example, if the target message is a will message, the second cancellation event can be the event that the server and the device successfully reconnect.

[0063] After receiving a status query request, the state machine engine can return the current status of the target transaction to the server; based on step 202, the current status can be the second status.

[0064] Step 204: When a cancellation request is received from the server in response to the second state, it is determined that a first cancellation event exists for the target message.

[0065] After receiving the current state, if the current state is the second state, the server can return a cancellation request to the state machine engine to request that the state of the target transaction be changed to the third state.

[0066] Conversely, if the current state is not the second state, the server can assume that there is an existing occupancy and will not return a cancellation request to the state machine engine.

[0067] For example, when the server returns a cancellation request to the state machine engine, it can request a "message cancellation handshake".

[0068] When the state machine engine receives a cancellation request, it can determine that a first cancellation event for the target message exists; in this case, the state machine engine can execute step 205. Conversely, if the state machine engine does not receive a cancellation request, it can determine that a first cancellation event for the target message does not exist; in this case, step 204 can be re-executed.

[0069] Step 205: When a first cancellation event occurs for the target message, the state of the target transaction is changed to the third state, and a first instruction to discard the target message is sent to the server; the server responds to the first instruction and discards the target message.

[0070] In some embodiments, after the state machine engine modifies the state of the target transaction from the first state to the second state, it can detect whether there is a first cancellation event for the target message.

[0071] After detecting the existence of a first cancellation event for the target message, the state machine engine can change the state of the target transaction from the second state to the third state; specifically, before making the change, the state machine engine can first check whether the current state of the target transaction is the second state.

[0072] If the target transaction is currently in the second state, the state machine engine can execute the step of changing the target transaction's state to the third state; conversely, if the target transaction is not currently in the second state, it means that it has been preempted by another process; in this case, the step of changing the target transaction's state from the second state to the third state can be skipped.

[0073] After the state machine engine changes the state of the target transaction from the second state to the third state, it can trigger the cancellation of the publication of the target message for the device; specifically, the state machine engine can send a first instruction to the server to discard the target message.

[0074] Upon receiving the first instruction, the server can respond by discarding the target message instead of publishing it, thereby avoiding issues such as false alarms, state fluctuations, and resource waste.

[0075] Step 206: Trigger the server to confirm the connection with the device.

[0076] In some embodiments, after the state machine modifies the state of the target transaction from the second state to the third state, it can also trigger the server to confirm the connection with the device.

[0077] Step 207: When there is a confirmation release event for the target message, change the state of the target transaction to the fourth state and send a second instruction to the server to release the target message; the server responds to the second instruction and releases the target message.

[0078] In some embodiments, after the state of the target transaction is changed from the first state to the second state, it is also possible to detect whether there is an acknowledgment publication event for the target message.

[0079] After detecting the existence of an acknowledgment publication event for the target message, the state machine engine can change the state of the target transaction from the second state to the fourth state; specifically, before making the change, the state machine engine can first check whether the current state of the target transaction is the second state.

[0080] If the target transaction is currently in state two, the state machine engine can execute the step of changing the target transaction's state to state four. Conversely, if the target transaction is not currently in state two, it means that it has been preempted by another process. In this case, the step of changing the target transaction's state from state two to state four does not need to be executed.

[0081] After the state machine engine changes the state of the target transaction from the second state to the fourth state, it can trigger the publication of the target message for the device; specifically, the state machine engine can send a second instruction to the server to publish the target message.

[0082] Upon receiving the second instruction, the server can respond by sending the target message to the subscriber.

[0083] In this embodiment, the state machine engine creates a target transaction for a target message from a device and sets the target transaction's state to a first state. When a publish event for the target message exists, the state of the target transaction is modified to a second state. In response to a state query request from the server, the second state of the target transaction is returned to the server. The state query request is generated by the server when it detects a second cancellation event for the target message. When a cancellation request is received from the server in response to the second state, a first cancellation event for the target message is determined. When a first cancellation event for the target message exists, the state of the target transaction is modified to a third state, and a first instruction to discard the target message is sent to the server. The server discards the target message in response to the first instruction. A connection confirmation is triggered between the server and the device. When a confirmed publish event for the target message exists, the state of the target transaction is modified to a fourth state, and a second instruction to publish the target message is sent to the server. The server publishes the target message in response to the second instruction. This embodiment avoids problems such as false alarms, state fluctuations, and resource waste.

[0084] The above describes the device message management method from the perspective of the state machine engine. Next, the device message management method will be described from the perspective of the server. Referring to FIG3, a flowchart of another device message management method according to an embodiment of the present application is shown, which may include the following steps: Step 301: The server registers the target message and triggers the state machine engine to create a target transaction for the target message, and triggers the state machine engine to set the state of the target transaction to the first state.

[0085] In some embodiments, the state machine engine can be deployed on a server connected to the device; after the device establishes a connection with the server, the server can create a session with the state machine engine and register target messages.

[0086] After registering the target message, the state machine engine creates a target transaction for the target message of the device.

[0087] After creating the target transaction, the state machine engine can first set the current state of the target transaction to the first state.

[0088] Step 302: When the device is detected to have triggered a publish event for the target message, the state machine engine is triggered to change the state of the target transaction to the second state.

[0089] In some embodiments, the server can detect the connection to the device and determine whether to trigger a publication event. For example, if the target message is a will message, the server can determine to trigger a publication event when it detects a transient network outage with the device (e.g., heartbeat timeout).

[0090] When the server detects a loss of connection with the device, it can notify the state machine engine of the connection loss, thereby triggering the state machine engine to change the state of the target transaction from the first state to the second state.

[0091] Before modifying the state, the state engine can first check whether the state of the target transaction is the first state; if the state of the target transaction is detected to be the first state, the state engine can execute the step of modifying the state of the target transaction from the first state to the second state.

[0092] Conversely, if the target transaction's state is detected to be not in the first state, the state engine can indicate that it has been preempted by another process; in this case, the state engine may not execute the step of changing the target transaction's state from the first state to the second state.

[0093] In some embodiments, when the state machine engine modifies the state of the target transaction from the first state to the second state, it can also start a delay timer for the target transaction to detect whether the reconnection between the server and the device has timed out.

[0094] Step 303: When a second cancellation event for the target message is detected, a status query request is sent to the state machine engine; the state machine engine is used to respond to the server's status query request and return the second status of the target transaction to the server.

[0095] When the server detects the second cancellation event, it can generate a status query request and send it to the state machine engine. The second cancellation event can be configured according to the specific circumstances; for example, if the target message is a will message, the second cancellation event could be an event indicating successful reconnection between the server and the device.

[0096] After receiving a state query request, the state machine engine can return the current state of the target transaction, i.e., the second state, to the server.

[0097] In some embodiments of this application, when the target message is a will message, the following sub-steps can be used to determine whether to trigger a second cancellation event: Sub-step 11, reconnect to the device.

[0098] In some embodiments, for example, the target message is a will message, and the server can actively attempt to reconnect to the device after the connection is lost.

[0099] Sub-step 12: When the device successfully reconnects to the server, determine that a second cancellation event for the target message has been detected.

[0100] When the device successfully reconnects to the server, the server can determine that a second cancellation event for the target message has been detected.

[0101] Conversely, if the device and the server fail to reconnect successfully, the server can determine that no second cancellation event was detected for the target message.

[0102] In some embodiments, it can also detect whether the device and the server have successfully reconnected if the delay time has not expired.

[0103] If the device and server successfully reconnect before the delay timeout expires, it can be determined that a second cancellation event for the target message was detected. Conversely, if the delay timeout expires, or if the device and server successfully reconnect only after the delay timeout has expired, it can be determined that no second cancellation event for the target message was detected.

[0104] Sub-step 13: Send a state query request to the state machine engine.

[0105] If a second cancellation event for the target message is detected, the server can send a state query request to the state machine engine to determine whether the will message can be published.

[0106] Step 304: In response to the second state, return a cancellation request to the state machine engine; In response to the cancellation request, the state machine engine determines that there is a first cancellation event for the target message and modifies the state of the target transaction to the third state.

[0107] After receiving the current state, the server can determine whether the current state is the second state. If the current state is the second state, the server can respond to the second state by returning a cancellation request to the state machine engine to request that the state of the target transaction be changed to the third state.

[0108] Conversely, if the current state is not the second state, the server can assume that there is an existing occupancy and will not return a cancellation request to the state machine engine.

[0109] For example, when the server returns a cancellation request to the state machine engine, it can request a "message cancellation handshake".

[0110] When the state machine engine receives a cancellation request, it can determine that there is a first cancellation event for the target message; at this time, the state machine engine can change the state of the target transaction from the second state to the third state.

[0111] Conversely, if the state machine engine does not receive a cancellation request, it can be determined that there is currently no first cancellation event for the target message; in this case, step 303 can be re-executed.

[0112] Step 305: When the target transaction is in the third state, cancel the publication of the target message for the device.

[0113] In some embodiments, if the server determines that the current state of the target transaction is a third state, the server may cancel the publication of the target message.

[0114] Specifically, when the state machine engine changes the state of the target transaction from the second state to the third state, it can return instructions to the server indicating that the handshake was successful, the connection was allowed, and the target message was discarded.

[0115] In response to this instruction, the server may choose not to publish the target message and may discard it; after discarding the target message, the server may also perform the operation of confirming the connection with the device.

[0116] Step 306: When the target transaction is in the fourth state, publish the target message.

[0117] In some embodiments, if the server determines that the current state of the target transaction is the fourth state, the server may publish the target message.

[0118] Specifically, when the state machine engine changes the state of the target transaction from the second state to the fourth state, it can return an instruction to the server to publish the target message. The server, in response to this instruction, can publish the target message.

[0119] In this embodiment, the server registers a target message and triggers a state machine engine to create a target transaction for the target message, and then triggers the state machine engine to set the state of the target transaction to a first state. When a device triggers a publish event for the target message, the state machine engine is triggered to modify the state of the target transaction to a second state. When a second cancellation event for the target message is detected, a state query request is sent to the state machine engine. The state machine engine responds to the server's state query request by returning the second state of the target transaction to the server. In response to the second state, a cancellation request is returned to the state machine engine. In response to the cancellation request, the state machine engine determines that a first cancellation event for the target message exists and modifies the state of the target transaction to a third state. When the state of the target transaction is in the third state, the publish of the target message for the device is cancelled. When the state of the target transaction is in the fourth state, the target message is published. Through this embodiment, problems such as false alarms, state fluctuations, and resource waste can be avoided.

[0120] Taking the target message as a will message and the target transaction as a will transaction as an example, and referring to Figure 4, a data interaction diagram of an embodiment of this application is shown: Implementation of the state machine engine: Defines the precise state of the will transaction: PENDING (standby), that is, the first state: when the connection is normal, the will transaction exists but is dormant.

[0121] SOFT_OFFLINE (soft offline), also known as the second state: connection lost, delayed start timer.

[0122] CANCELLED (Cancelled), which is the third state: In the SOFT_OFFLINE state, the device successfully reconnected, and the will message was canceled from being published.

[0123] FINAL_OFFLINE, also known as the fourth state, is the delay timeout, and the will message is published.

[0124] This state machine precisely depicts the intermediate states of a will's lifecycle, and its state transition logic (such as the ability to cancel only in the SOFT_OFFLINE state) can accurately manage will messages.

[0125] Implementation of the will transaction object: The following is a data structure inside the Broker that encapsulates all the context of a potential will issuance.

[0126] class WillTransaction { String clientId; encapsulates a clientId containing a unique identifier String willTopic; the topic to which the message is published willTopic; byte[] willMessage; the message containing willMessage; int willQos; the quality of service level willQos; long willDelayInterval; the delay time value willDelayInterval; Timer delayTime; / / delay timer; the timer object delayTimer; WillState currentState; the current state (PENDING, SOFT_OFFLINE...); Objectlock; / used for concurrency control}; This application elevates the will message from an attribute of the connection session to an independent, stateful lifecycle object, which is the foundation for achieving fine-grained management.

[0127] Specifically, in the first phase: connection and session establishment, when the device sends a CONNECT to the server, it can carry willTopic, willMessage, and willDelayInterval; based on CONNECT, the server can create a session for the will message and register the will message with the state machine engine; the state machine engine can create the will transaction and set the state to PENDING.

[0128] When the network is momentarily interrupted (e.g., heartbeat timeout), the second stage can be entered: connection failure and state switching. At this time, the server will notify the state machine engine of the connection loss. At this time, the delay timer can be started, and the state of the will transaction can be switched from PENDING to SOFT_OFFLINE. At this time, the "soft offline" delay window is entered.

[0129] In the third phase, the decision-making process within the delay window, the server and device can attempt to reconnect within the window. Once the device successfully reconnects to the server with the same device ID, the server will query the state machine engine for the status of the will transaction for that device ID. The state machine engine can return the current status to the server; if the current status is SOFT_OFFLINE, the server will perform a "will cancellation" handshake.

[0130] The state machine engine can cancel the delayed timer. Upon successful cancellation, the state machine engine switches the will transaction state from SOFT_OFFLINE to CANCELLED, notifies the server of a successful handshake and permission to connect to the device, and instructs the server to discard the will message. At this point, the server can send a CONNACK to the device. The connection is then restored, and the will message publication is cancelled.

[0131] When the delay window times out, i.e., the delay timer expires, the state machine engine switches the will transaction state from SOFT_OFFLINE to FINAL_OFFLINE and sends a command to the server to instruct the server to publish the will message. At this point, the device is determined to be truly offline, and the will message is published. At this time, willMessage can be published to willTopic.

[0132] In this embodiment, the sole responsibility of the timer object (delayTimer) is to measure the duration of the "soft offline" state. More specifically, this timer is created and started when the state of the WillTransaction object changes from PENDING to SOFT_OFFLINE, with a set duration of willDelayInterval. Its existence indicates that the system is in an "observation and wait" mode. When it times out, it does not directly issue a will, but instead sends a "delay timeout event" to the state machine engine. This timer object is an "event trigger," not an "action executor."

[0133] Implementation of the "Will Cancellation Handshake" protocol: When a device reconnects in the SOFT_OFFLINE state, the Broker does not directly allow it, but triggers an internal handshake: Query: Query the state machine engine for the will transaction status of the ClientID.

[0134] Decision: The state machine engine detects that the state is SOFT_OFFLINE.

[0135] Cancel action: The state machine engine atomically executes two operations: a) cancel delayTimer; b) set the state to CANCELLED.

[0136] Resource cleanup: Clean up old connection sessions and mark WillTransaction as recyclable.

[0137] Connection allowed: Handshake successful, new connection allowed to be established.

[0138] This is a lightweight coordination protocol within the Broker. It ensures the atomicity and consistency of the "cancel" operation under concurrent conditions (when timer timeouts and device reconnection occur almost simultaneously), avoiding the erroneous publication of wills caused by race conditions.

[0139] Specifically, the modification of the currentState field in the will transaction object uses atomic "compare and swap". Operation thread 1: Timer timeout thread, which does only one thing: attempts to change the state from "soft offline" to "finally offline". Thread 2: Device reconnection thread, which also does only one thing: attempts to change the state from "soft offline" to "cancelled", and the states do not interfere with each other.

[0140] In this embodiment, CAS combines the "check state" and "set state" into a single, uninterruptible CPU instruction. When a thread executes CAS, it is not preempted from CPU time slices, thus fundamentally eliminating the aforementioned "read-determine-write" trap.

[0141] The currentState field is the sole source of truth determining the will's fate. Any thread wishing to alter the will's destiny must compete for the right to modify this unique field using CAS (Compare-and-Swap).

[0142] CAS operations have explicit return values ​​(success or failure). A failing thread will know it has failed and will therefore avoid performing subsequent dangerous operations. It will not publish a will that has already been cancelled, nor will it cancel a connection that has already been timed out.

[0143] "Using atomic comparison and swap" means that we use a single, indivisible, special instruction provided by the computer hardware (CPU) to update the data. This instruction operates as an uninterrupted whole, performing both the "comparison" and "swap" operations. It compares the current state of the will with the desired current state; if so, it modifies it to the new state.

[0144] This application is not merely a "delayed will release" feature, but rather the construction of an internal governance system running on the Broker side, based on a dual-sequence state machine and delayed window collaborative management. Specifically, this application introduces a "soft offline state" and a state machine engine, defining a new, temporary "soft offline" state between the standard "online" and "offline" states, and specifying strict entry, maintenance, and exit conditions. The operation is an atomic combination of three steps: "read-compare-write." During execution, it checks whether the current state is equal to the expected state `expectedState`. If so, it instantly sets it to the required state `newState`, without being interrupted by any other threads throughout the process.

[0145] This application also designs a "two-way handshake" protocol within the "delay window": during the delay period, the Broker does not wait passively, but actively manages and executes a lightweight internal protocol with the device attempting to reconnect to determine whether to "cancel the will" or "confirm offline".

[0146] The complete lifecycle is encapsulated through "will transactions": a will triggering attempt is encapsulated as a stateful transaction object, whose lifecycle is driven by an internal state machine. This decouples the will trigger from the device connection session (the will trigger is encapsulated as a transaction object and stored in an independent session management module. This object is different from the original will message (an attribute of the device connection session), and the two coexist. The processing of the transaction object does not affect the original will message, thus achieving decoupling) but they are still interconnected.

[0147] In the standard implementation, the will message (subject, message) is simply a few fields in the device connection session object. The will is published immediately upon disconnection of the MQTT connection.

[0148] There are no "transactions" here, only "triggers". The fate of a will is strongly coupled with the liveness of a TCP connection.

[0149] In this application, the "will" is an independent transaction object: 1. "Encapsulation": The will message, delay logic, timer and trigger state scattered in the session object are packaged into a unified, self-contained software entity (i.e., the WillTransaction class), such as the code segment in the specific implementation.

[0150] 2. "A will-triggered attempt": This object does not represent the final publication action, but rather "a complete process that may eventually lead to the publication of a will".

[0151] 3. "Stateful": This process is not completed instantaneously; it has its own development stages. The "explicit behavioral rules" of each state mean that in a specific state, the system will only respond to specific events and perform state transitions according to a defined path, ultimately reaching one and only one termination state.

[0152] 4. "Transaction Object": Like database transactions, it pursues the "C" (consistency) in ACID: it must eventually reach a consistent and deterministic state (either cancel or publish), and intermediate or chaotic states are not allowed. It has its own beginning, process, and end.

[0153] This application achieves architectural decoupling by introducing the independent concept of testamentary affairs and designing a precise state machine for it. This is not merely implementing a function, but defining a new, controllable, and observable lifecycle model.

[0154] By introducing a state machine engine, will transactions, and an internal cancellation handshake protocol, this application solves the industry problem of "false triggering": through precise "soft offline" state management, it fundamentally filters out noise caused by network interruptions.

[0155] Furthermore, this application also achieves precise governance of internal states: through multi-state definitions and transition rules, the behavior of the system within the delay window is deterministic and predictable (a state machine is introduced as the central arbiter, and atomic operations are used to ensure the mutual exclusion of state changes, so that in complex concurrent environments, the system's handling of each connection exception is unique and predictable).

[0156] Furthermore, this application guarantees eventual consistency of the system under high concurrency: through atomic operations in the "cancel handshake" protocol (state mutual exclusion: if one thread can successfully execute an operation, another thread will inevitably fail, due to the competition for locks. If one thread processes the publication of a will, then no other thread can process the cancellation of that will.), the logical chaos of will messages being "both published and cancelled" that may occur in critical states is avoided.

[0157] This application provides a general framework for enhancing connection reliability: this "state machine + delay window" management pattern can be applied to various communication protocols that require distinguishing between "transient anomalies" and "persistent failures." For example, in a microservice architecture, service instances report heartbeats to the service registry to prove their existence. However, network fluctuations may cause temporary interruptions in heartbeats. If the registry immediately deregisters the service instance after the first lost heartbeat, the service will be incorrectly removed from the available list, leading to numerous upstream call failures and causing service "shock." Using this management pattern, when a session anomaly is detected, the lock is not immediately closed but enters a grace period, similar to a delayed will. Only if the anomaly persists after the grace period is the service deregistered.

[0158] In the MQTT server architecture of this application embodiment, the threads participating in the competition typically correspond to execution units that handle different tasks. These mainly involve the following two types: Network I / O threads (or connection processing threads): This thread pool is responsible for handling all external network requests. When a device attempts to reconnect, it is this type of thread that receives the new CONNECT message and triggers the "cancel handshake" logic. We call it the "reconnection thread".

[0159] Timer thread (or timeout management thread): This thread pool is responsible for managing all scheduled tasks. When the delay time `willDelayInterval` set for `WillTransaction` expires, it is this type of thread that triggers the timeout callback and executes the "timeout publish" logic. We call it the "timeout thread".

[0160] Therefore, the competition occurs when a "reconnection thread" and a "timeout thread" are trying to decide the final fate of the same will matter almost simultaneously.

[0161] In this embodiment, instead of using traditional synchronized or Lock (which have significant performance overhead), a lighter-weight "lock-free programming" technique is used, the core of which is the "compare and swap" instruction. This CAS instruction is itself a low-level, hardware-implemented "contention lock".

[0162] When a thread comes in, it first checks the current state, such as SOFT_OFFLINE. If it wants to change it to CANCELLED, it checks the current state again at the moment of modification. If it is SOFT_OFFLINE, it immediately changes it to the new value CANCELLED. If not, it means that another thread has already modified it, for example, by changing it to FINAL_OFFLINE, so its modification will not be executed.

[0163] This continuous "see-check-write" action is atomically guaranteed by the CPU and cannot be interrupted. This is what is meant by "atomic operation," which acts as a contention lock, ensuring that only one thread can successfully update the state.

[0164] Competition for lock process: (1) Initial state: The state of the WillTransaction object is SOFT_OFFLINE. Its delay timer is counting down.

[0165] (2) Concurrent event triggering: Event A (Device reconnection): The device's TCP connection request is received by the server and processed by a reconnection thread. It parses out the ClientID and finds the corresponding WillTransaction object.

[0166] Event B (Delay Timeout): The countdown ends, the timeout thread is triggered, and it obtains the same WillTransaction object.

[0167] (3) Competition begins: At almost the same moment, both the reconnection thread and the timeout thread call the willTransaction.transitionState(...) method.

[0168] Reconnection thread request: (SOFT_OFFLINE->CANCELLED); Timeout thread request: (SOFT_OFFLINE->FINAL_OFFLINE); (4) CPU arbitration (competition for lock / atomic operation takes effect): The CPU guarantees that these two CAS operations will be executed sequentially (although they are sequential in a microscopic sense, they are logically competing "simultaneously".

[0169] Scenario 1 (Reconnection Successful): Assume the CAS operation of the reconnection thread executes first. It finds the state is SOFT_OFFLINE, consistent with the expected value, and successfully changes it to CANCELLED. Subsequently, the CAS operation of the timeout thread executes, finds the state is already CANCELLED, which does not match the expected SOFT_OFFLINE, and therefore fails, returning false.

[0170] Scenario 2 (Timeout wins): The process is reversed. The timeout thread successfully changes the status to FINAL_OFFLINE, while the reconnection thread fails.

[0171] (5) Subsequent actions (the result is determined and there is no competitive state): the winner performs the final, safe operation based on the true returned by the success.

[0172] The reconnection thread wins: cleans up the delay timer, allowing new sessions to be established. The will is cancelled.

[0173] The thread that timed out wins: it executes the publishWillMessage() method and publishes the will.

[0174] Upon receiving a false error, the failing thread does nothing and silently exits. This is because it knows its operation was based on an outdated premise, and the system state has been updated by another thread.

[0175] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of this application.

[0176] Referring to Figure 5, a schematic diagram of a device message management apparatus according to an embodiment of this application is shown, applied to a state machine engine. The apparatus may include the following modules: a setting module 501, used by the state machine engine to create a target transaction for a target message of a device, and set the state of the target transaction to a first state; a first modification module 502, used to modify the state of the target transaction to a second state when a publish event for the target message exists; a second modification module 503, used to modify the state of the target transaction to a third state when a first cancellation event for the target message exists, and trigger the cancellation of the publish of the target message for the device; and a third modification module 504, used to modify the state of the target transaction to a fourth state when a confirmation publish event for the target message exists, and trigger the publish of the target message for the device.

[0177] In some embodiments, the state machine engine is deployed on the server side, and the second modification module 503 is further configured to return a second state of the target transaction to the server side in response to a state query request from the server side; the state query request is a request generated by the server side when it detects a second cancellation event for the target message; when the server side receives a cancellation request in response to the second state, it is determined that a first cancellation event for the target message exists.

[0178] In some embodiments, the state machine engine is deployed on the server, and the second modification module 503 is used to send a first instruction to the server to discard the target message; the server responds to the first instruction to discard the target message; and triggers the server to confirm the connection with the device.

[0179] In some embodiments, the state machine engine is deployed on the server side, and the third modification module 504 is used to send a second instruction to the server to publish the target message; the server responds to the second instruction to publish the target message.

[0180] In some embodiments, the first modification module 502 is further configured to start a delay timer for the target transaction when the state of the target transaction is modified to the second state.

[0181] In some embodiments, the first modification module 502 is further configured to detect whether the delay timer has expired; when the delay timer expires, it is determined that there is an acknowledgment release event for the target message.

[0182] In this embodiment, the state machine engine creates a target transaction for a target message from a device and sets the target transaction's state to a first state. When a publish event for the target message occurs, the state of the target transaction is changed to a second state. When a first cancellation event for the target message occurs, the state of the target transaction is changed to a third state, and the publication of the target message for the device is cancelled. When a confirm publish event for the target message occurs, the state of the target transaction is changed to a fourth state, and the publication of the target message for the device is triggered. This embodiment avoids problems such as false alarms, state fluctuations, and resource waste.

[0183] This application achieves "phased and refined release of resources," while simple delays merely result in "overall idle waiting of resources." This application uses decoupled transaction objects to achieve: 1. Immediate release. When the connection is broken, TCP stack-related resources are immediately reclaimed by the operating system.

[0184] 2. The vast majority of the data is released. Only a lightweight WillTransaction object (with a few fields) is retained, while the large Session object is destroyed.

[0185] 3. The vast majority of the data is released. Only a lightweight WillTransaction object (with a few fields) is retained, while the large Session object is destroyed.

[0186] In addition, this application can also solve the black box problem in the following ways: 1. Clarify the status: By querying the status of WillTransaction, it can be known that the device is in the SOFT_OFFLINE (soft offline) state.

[0187] 2. The process is visible: Because there is a state transition record, it can be known whether a will was canceled because it received a CANCELLED event (i.e., device reconnection) or because it timed out and entered FINAL_OFFLINE.

[0188] 3. Precise Measurement: It can easily expose the following indicators: -will_transactions_pending; -will_transactions_soft_offline; -will_transactions_cancelled; -will_transactions_final_offline; These are the gold indicators of system health.

[0189] 4. Easy to diagnose: The logs can clearly record every transition of the state machine: "Client[A] moves from PENDING to SOFT_OFFLINE", "Client[A] moves from SOFT_OFFLINE to CANCELLED"; maintenance personnel can review the entire event as if looking at a flowchart.

[0190] Referring to Figure 6, a schematic diagram of another device message management device according to an embodiment of this application is shown. This device is applied to a server, where a state machine engine is deployed. The device may include the following modules: a first trigger module 601, used to register a target message on the server, trigger the state machine engine to create a target transaction for the target message, and trigger the state machine engine to set the state of the target transaction to a first state; a second trigger module 602, used to trigger the state machine engine to modify the state of the target transaction to a second state when a device triggers a publication event for the target message; and a first request module 603, used to request a device message publication event for the target message. Upon the second cancellation event, a status query request is sent to the state machine engine; the state machine engine responds to the server's status query request by returning the second status of the target transaction to the server; the second request module 604 responds to the second status by returning a cancellation request to the state machine engine; the state machine engine responds to the cancellation request by determining that a first cancellation event exists for the target message and modifies the status of the target transaction to the third status; the cancellation module 605 cancels the publication of the target message for the device when the status of the target transaction is the third status; the publication module 606 publishes the target message when the status of the target transaction is the fourth status.

[0191] In some embodiments, the target message is a will message. The first request module 603 is used to reconnect with the device. When the device successfully reconnects with the server, it determines that a second cancellation event for the target message has been detected and sends a status query request to the state machine engine.

[0192] In this embodiment, the server registers a target message and triggers a state machine engine to create a target transaction for the target message, and then triggers the state machine engine to set the state of the target transaction to a first state. When a device triggers a publish event for the target message, the state machine engine is triggered to modify the state of the target transaction to a second state. When a second cancellation event for the target message is detected, a state query request is sent to the state machine engine. The state machine engine responds to the server's state query request by returning the second state of the target transaction to the server. In response to the second state, a cancellation request is returned to the state machine engine. In response to the cancellation request, the state machine engine determines that a first cancellation event for the target message exists and modifies the state of the target transaction to a third state. When the state of the target transaction is in the third state, the publish of the target message for the device is cancelled. When the state of the target transaction is in the fourth state, the target message is published. Through this embodiment, problems such as false alarms, state fluctuations, and resource waste can be avoided.

[0193] This application also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, it implements the above-described device message management method.

[0194] This application also provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, it implements the above-described device message management method.

[0195] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0196] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0197] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0198] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0199] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0200] These computer program instructions may also be loaded onto a computer or other programmable data processing terminal equipment to cause a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable terminal equipment, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0201] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0202] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0203] The above provides a detailed description of a device message management method, apparatus, electronic device, and storage medium. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for managing device messages, characterized in that, The method, applied to a state machine engine, includes: the state machine engine creating a target transaction for a target message of the device and setting the state of the target transaction to a first state; when a publish event for the target message occurs, modifying the state of the target transaction to a second state; when a first cancellation event for the target message occurs, modifying the state of the target transaction to a third state and triggering the cancellation of the publish of the target message for the device; and when a confirm publish event for the target message occurs, modifying the state of the target transaction to a fourth state and triggering the publish of the target message for the device.

2. The method according to claim 1, characterized in that, The state machine engine is deployed on the server side, and the method further includes: responding to the server side's state query request, returning the second state of the target transaction to the server side; the state query request is a request generated by the server side when it detects a second cancellation event for the target message; when the server side receives a cancellation request in response to the second state, it determines that a first cancellation event exists for the target message.

3. The method according to claim 1, characterized in that, The state machine engine is deployed on the server side. Triggering the cancellation of the publication of the target message for the device includes: sending a first instruction to the server to discard the target message; the server responding to the first instruction to discard the target message; and triggering the server to confirm the connection with the device.

4. The method according to claim 1, characterized in that, The state machine engine is deployed on the server side. Triggering the publication of the target message for the device includes: sending a second instruction to the server to publish the target message; and the server responding to the second instruction to publish the target message.

5. The method according to claim 1, characterized in that, When modifying the state of the target transaction to the second state, the method further includes: initiating a delay timer for the target transaction.

6. The method according to claim 5, characterized in that, The method further includes: detecting whether the delay timer has expired; when the delay timer expires, determining that there is an acknowledgment release event for the target message.

7. A method for managing device messages, characterized in that, The method is applied to a server-side application, wherein a state machine engine is deployed on the server. The method includes: the server registering a target message and triggering the state machine engine to create a target transaction for the target message, and triggering the state machine engine to set the state of the target transaction to a first state; when a device triggers a publish event for the target message, the state machine engine is triggered to modify the state of the target transaction to a second state; when a second cancellation event for the target message is detected, a state query request is sent to the state machine engine; the state machine engine, in response to the server's state query request, returns the second state of the target transaction to the server; in response to the second state, returns a cancellation request to the state machine engine; in response to the cancellation request, the state machine engine determines that a first cancellation event exists for the target message and modifies the state of the target transaction to a third state; when the state of the target transaction is the third state, the publish of the target message for the device is cancelled; when the state of the target transaction is a fourth state, the target message is published.

8. The method according to claim 7, characterized in that, The target message is a will message. When a second cancellation event is detected for the target message, sending a status query request to the state machine engine includes: reconnecting with the device; when the device successfully reconnects with the server, determining that a second cancellation event for the target message has been detected; and sending the status query request to the state machine engine.

9. A device for managing device messages, characterized in that, The device, applied to a state machine engine, includes: a setting module for creating a target transaction for a target message of the device and setting the state of the target transaction to a first state; a first modification module for modifying the state of the target transaction to a second state when a publish event for the target message occurs; a second modification module for modifying the state of the target transaction to a third state and triggering the cancellation of the publish of the target message for the device when a first cancellation event for the target message occurs; and a third modification module for modifying the state of the target transaction to a fourth state and triggering the publish of the target message for the device when a confirm publish event for the target message occurs.

10. A device for managing device messages, characterized in that, The device is applied to a server-side application, wherein a state machine engine is deployed on the server. The device includes: a first triggering module, configured to register a target message on the server, trigger the state machine engine to create a target transaction for the target message, and trigger the state machine engine to set the state of the target transaction to a first state; a second triggering module, configured to trigger the state machine engine to modify the state of the target transaction to a second state when a device triggers a publish event for the target message; a first request module, configured to send a state query request to the state machine engine when a second cancellation event for the target message is detected; the state machine engine, configured to respond to the server's state query request and return the second state of the target transaction to the server; the second request module, configured to respond to the second state and return a cancellation request to the state machine engine; the state machine engine, in response to the cancellation request, determines that a first cancellation event for the target message exists and modifies the state of the target transaction to a third state; a cancellation module, configured to cancel the publish of the target message for the device when the state of the target transaction is the third state; and a publish module, configured to publish the target message when the state of the target transaction is a fourth state.

11. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the device message management method as described in any one of claims 1 to 8.

12. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the device message management method as described in any one of claims 1 to 8.

Images