Session recovery method, apparatus, and computer storage medium

Abstract

The application provides a session recovery method, device and computer storage medium. The session recovery method comprises the following steps: in response to an abnormal communication link between a communication local end and a communication opposite end, adding a message to be recovered to a buffer queue of the communication local end; in response to the recovery of the communication link, screening the message in the buffer queue based on session metadata of the communication local end and session metadata of the communication opposite end to obtain a replay message queue; and sending the message in the replay message queue to the communication opposite end to recover the session between the communication local end and the communication opposite end. Through the session recovery method, message loss during session recovery is avoided, and continuity and integrity of events in the session are ensured.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and in particular to a session recovery method, device, and computer storage medium. Background Technology

[0002] In IoT multi-agent terminal collaborative communication scenarios, the industry has built the ACP (Agent Communication Protocol) session mechanism, which is a continuous two-way dedicated communication session channel established between IoT smart terminals.

[0003] Due to factors such as wireless network signal jitter, established ACP sessions are prone to abnormal disconnection and link interruption. Existing technologies, after detecting the disconnection of the communication link of an ACP session, will continue to resend the unsent message packets and service instructions cached before the disconnection after the communication link is restored. This can easily lead to message loss, cannot guarantee the continuity and integrity of events in the session, and is prone to problems such as service event gaps and interaction logic disorder. Summary of the Invention

[0004] To address the aforementioned technical problems, this application proposes a session recovery method, apparatus, and computer storage medium.

[0005] To address the aforementioned technical problems, this application proposes a session recovery method, comprising: in response to a communication link anomaly between a local communication terminal and a peer communication terminal, adding messages to be recovered to a buffer queue of the local communication terminal, the buffer queue being used to store messages that the local communication terminal failed to send to the peer communication terminal; in response to the recovery of the communication link, filtering the messages in the buffer queue based on the session metadata of the local communication terminal and the session metadata of the peer communication terminal to obtain a replay message queue, wherein the sending order of the messages in the replay message queue is not earlier than the sending order of the most recent consecutive messages, the most recent consecutive message being the last message among multiple consecutive messages that the peer communication terminal has acknowledged receiving; and sending the messages in the replay message queue to the peer communication terminal to restore the session between the local communication terminal and the peer communication terminal.

[0006] The session metadata includes a session identifier and a session snapshot identifier. Based on the session metadata of the local communication terminal and the session metadata of the peer communication terminal, messages in the buffer queue are filtered to obtain a replay message queue. This includes: in response to a match between the session identifier of the local communication terminal and the session identifier of the peer communication terminal, and a match between the session snapshot identifier of the local communication terminal and the session snapshot identifier of the peer communication terminal, determining a replay start point based on the most recently received consecutive messages acknowledged by the peer communication terminal, and determining a replay end point based on the most recently unacknowledged received messages in the local communication terminal; and filtering messages in the buffer queue based on the replay start point and the replay end point to obtain the replay message queue.

[0007] The process of filtering messages in the buffer queue based on the replay start point and the replay end point includes: filtering messages in the buffer queue that fall between the replay start point and the replay end point to obtain an initial message queue; and filtering messages in the initial message queue based on the preset maximum number of messages in the replay message queue and the priority level of each message in the initial message queue to obtain the replay message queue.

[0008] The step of sending messages from the replay message queue to the communication peer includes: dividing the replay message queue into multiple message sub-queues based on priority levels, wherein the messages in each message sub-queue have the same priority level and are arranged in ascending order of sequence number; traversing all the message sub-queues in descending order of priority level, and sending the messages in the currently traversed message sub-queue in ascending order of sequence number each time a message sub-queue is traversed.

[0009] The session recovery method further includes: in response to the recovery of the communication link, receiving a recovery message sent by the communication peer; performing service deduplication verification on the recovery message, and determining whether to process the recovery message based on the verification result.

[0010] The process of performing service deduplication verification on the recovery message and determining whether to process the recovery message based on the verification result includes: comparing the current sequence number of the recovery message with the expected sequence number; if the current sequence number is greater than the expected sequence number, determining that the recovery message is an early arrival message, caching the recovery message in the pending message set, and processing the recovery message based on the recovery message when all messages between the expected sequence number and the current sequence number are received; if the current sequence number is less than the expected sequence number and falls within a preset receiving window, determining whether the recovery message is a duplicate message; and if the recovery message is not a duplicate message, processing the recovery message based on the recovery message.

[0011] The determination of whether the recovery message is a duplicate message includes: determining whether the message identifier of the recovery message is the same as the message identifier of the processed message within a preset time window; if yes, the recovery message is determined to be a duplicate message; if no, the determination of whether it is a duplicate message is based on the timestamp of the recovery message and the timestamp of the historical message.

[0012] The session recovery method further includes: recording the duration of the communication link anomaly; when the duration exceeds a preset latency threshold, executing at least one of the following degradation strategies: discarding messages to be recovered with a preset priority, generating an event continuity interruption flag, triggering an anomaly warning message at the local communication end and saving a complete video recording at the local communication end, re-establishing a new session with a recovery failure flag, requesting manual intervention, or requesting an event summary from a cloud event storage platform.

[0013] To address the aforementioned technical problems, this application also proposes a session recovery device, which includes a memory and a processor coupled to the memory; wherein the memory is used to store program data, and the processor is used to execute the program data to implement the session recovery method as described above.

[0014] To address the aforementioned technical problems, this application also proposes a computer storage medium for storing program data, which, when executed by a computer, is used to implement the aforementioned session recovery method.

[0015] Compared with the prior art, the beneficial effects of this application are as follows: when the communication link between the local end and the peer end is abnormal, the message to be restored is stored in a buffer queue to cache the message that was not successfully sent to the peer end due to the communication link failure, thus avoiding message loss; after the communication link is restored, the session metadata of the local end and the peer end are exchanged, and the replay message queue is filtered based on the most recent consecutive message that the peer end has confirmed to receive, thus avoiding duplicate message sending. By sending the message in the replay message queue, message loss is avoided when the session is restored, ensuring the continuity and integrity of events in the session. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein: Figure 1 This is a flowchart illustrating an embodiment of the session recovery method provided in this application; Figure 2 This is a schematic diagram of the architecture of the session recovery system provided in this application; Figure 3 This is a schematic diagram of the session recovery process in another embodiment provided in this application; Figure 4 This is a schematic diagram of the structure of an embodiment of the session recovery device provided in this application; Figure 5 This is a schematic diagram of the structure of an embodiment of the computer storage medium provided in this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0018] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0019] The session recovery method of this application is applied to a session recovery device, which can be a server, a terminal device, or a system in which the server and the terminal device cooperate with each other. Accordingly, the various parts of the session recovery device, such as various units, sub-units, modules, and sub-modules, can all be set in the server, all in the terminal device, or separately in the server and the terminal device.

[0020] Furthermore, the aforementioned server can be either hardware or software. When the server is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When the server is software, it can be implemented as multiple software programs or software modules, such as software or software modules used to provide distributed server functionality, or as a single software program or software module; no specific limitations are made here.

[0021] Please refer to details. Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the session recovery method provided in this application, as shown below. Figure 1 As shown, the specific steps are as follows: Step S11: In response to an anomaly in the communication link between the local communication terminal and the peer communication terminal, add the message to be recovered to the buffer queue of the local communication terminal. The buffer queue is used to store messages that the local communication terminal failed to send to the peer communication terminal. In this embodiment of the application, the local communication terminal and the peer communication terminal are two communication terminals participating in the session interaction, one of which is the local communication terminal and the other is the peer communication terminal.

[0022] Taking smart cameras as an example, smart cameras are widely used in core business scenarios such as home care, abnormal alarms, cloud verification, device linkage, and mobile phone push notifications. The normal operation of the above business scenarios depends on the continuous and stable session communication between smart cameras and proxy nodes such as the cloud, mobile terminals (such as mobile phones), and edge gateways. Edge gateways are preferably deployed in nearby gateway devices.

[0023] The local communication terminal and the peer communication terminal can be any two terminals that maintain a session, such as smart cameras, cloud-side devices, mobile phones, edge gateways, etc.

[0024] The sessions between smart cameras and proxy nodes such as cloud devices, mobile phones, and edge gateways carry device status messages, as well as various key event messages such as intrusion anomalies, people falling, fire hazards, doorbell visitors, and pet anomalies, and core business data such as event fragment indexes, device linkage control commands, and message receipt confirmation information.

[0025] The network environment in which a smart camera is located may experience problems such as Wi-Fi signal fluctuations, broadband interruptions, router restarts, high latency due to weak networks, uplink congestion, network address translation mapping failures, and mobile terminals switching between cellular networks and Wi-Fi. These issues can lead to abnormal communication links between the local and remote ends, resulting in temporary interruptions of the session between them.

[0026] The session between the local communication end and the communication peer can be an ACP (Agent Communication Protocol) session.

[0027] After a temporary interruption of the session between the local end and the peer end, the session recovery mechanism needs to wake up the original ACP session when the communication link is restored, and continue the communication tasks before the session interruption, so as to ensure that unprocessed messages can be exchanged normally and avoid data corruption problems caused by session reconstruction.

[0028] The local communication terminal is equipped with a buffer queue module. When the buffer queue module detects an anomaly in the communication link between the local communication terminal and the peer communication terminal, it triggers message caching processing and stores all messages waiting to be resent into a pre-set buffer queue on the local communication terminal. The buffer queue stores messages that have not yet been successfully sent to the peer communication terminal to avoid message loss.

[0029] In this process, after the local end of the communication network sends a message to the other end, the other end will send back an acknowledgment message upon receiving the message. The local end then determines whether the message was successfully sent to the other end based on whether it received the acknowledgment message.

[0030] The messages stored in the buffer queue on the local end that have not yet been successfully sent to the other end are divided into three categories: messages that have been sent out but have not received confirmation information from the other end, messages that were generated before the communication link was interrupted but have not yet been sent, and messages newly generated during the session interruption phase.

[0031] The local communication terminal is equipped with a link detection module, which monitors at least one of the following anomaly indicators of the communication link: number of consecutive heartbeat timeouts, number of times acknowledgment messages are not returned, average latency and jitter amplitude, packet loss rate, number of reconnections, session failure rate, and sudden changes in wireless signal strength.

[0032] When the anomaly detection index meets the preset anomaly conditions, the communication link is determined to be abnormal. Furthermore, the communication link anomaly is divided into two types: mild jitter and severe interruption. When the communication link is in mild jitter, the local communication terminal can still receive and send messages, but there is a significant delay. When the communication link is in severe interruption, the long connection of the communication link is broken, the heartbeat times out multiple times in a row and no acknowledgment information is received.

[0033] Once an anomaly is detected in the communication link, the session state is switched to the buffer state, a session snapshot of the moment of the link anomaly is immediately generated, outgoing message transmission is suspended, messages that were not successfully sent from the local end to the peer end are written into the buffer queue, and the sequence number, message identifier, event identifier, generation time, priority level, message type and retransmission count are registered for each message in the buffer queue. At the same time, the acknowledgment level of the local end is saved.

[0034] The acknowledgment level at the local end of the communication refers to the sequence number of the most recent consecutive messages for which an acknowledgment message has been received from the peer end of the communication, while the acknowledgment level at the peer end of the communication refers to the sequence number of the most recent consecutive messages for which an acknowledgment message has been generated from the peer end of the communication.

[0035] Step S12: In response to the restoration of the communication link, based on the session metadata of the local communication terminal and the session metadata of the peer communication terminal, the messages in the buffer queue are filtered to obtain a replay message queue, wherein the sending order of the messages in the replay message queue is not earlier than the sending order of the most recent consecutive messages, and the most recent consecutive messages are the last message among the multiple consecutive messages that the peer communication terminal has confirmed to have received.

[0036] In this embodiment of the application, when the communication link is restored, the local communication end will not directly send the messages in the buffer queue, nor will it send all the messages in the buffer queue. Instead, when the communication link is restored, the session metadata of the two communication ends is exchanged first to synchronize the message sending and receiving progress of the two communication ends. The session metadata is a set of control parameters stored by the communication end to maintain the session state, and does not include the messages carried in the session themselves.

[0037] Before the communication link failure, some messages sent by the local end of the communication network had been successfully sent to the other end of the communication network, and the other end had generated an acknowledgment message. However, due to the communication link failure, the acknowledgment message was blocked on the way back and was not successfully received by the local end of the communication network. These messages will still be stored in the buffer queue. If the local end of the communication network resends all the messages to be recovered in the buffer queue, the messages that have been received by the other end will be retransmitted, resulting in a large number of messages being sent repeatedly.

[0038] To avoid sending a large number of messages repeatedly, the messages in the buffer queue are filtered based on the session metadata exchanged between the local end and the peer end of the communication to obtain a replay message queue.

[0039] After receiving a message, the other end of the communication will generate a corresponding acknowledgment message to mark the message as confirmed received. The last message in a series of consecutive messages that the other end of the communication has confirmed received is the most recent consecutive message. All messages before the most recent consecutive message have been confirmed received by the other end of the communication.

[0040] Optionally, the communication peer will add messages that are received in real time and whose preceding messages have all been received to the continuous message sequence, and the message at the end of the continuous message sequence is the most recent continuous message.

[0041] Messages are filtered based on their sending order. Messages on the local communication end have a preset sending order to ensure that the message transmission sequence is regular. Messages in the buffer queue that are sent after the most recent consecutive messages are added to the replay message queue.

[0042] The local end of the communication sends messages in a preset sending order. All messages sent before the most recent consecutive messages have been received and confirmed by the other end of the communication and do not need to be resent. However, the confirmation information of some messages may be blocked during the return transmission and will still be stored in the buffer queue by the local end of the communication. Therefore, the messages in the buffer queue are filtered, and messages whose sending order is not earlier than the most recent consecutive messages are added to the replay message queue.

[0043] In an optional embodiment, the session metadata includes a session identifier and a session snapshot identifier; based on the session metadata of the local communication terminal and the session metadata of the peer communication terminal, the messages in the buffer queue are filtered to obtain a replay message queue, including: in response to the session identifier of the local communication terminal matching the session identifier of the peer communication terminal, and the session snapshot identifier of the local communication terminal matching the session snapshot identifier of the peer communication terminal, determining the replay start point based on the most recently received consecutive messages confirmed by the peer communication terminal, and determining the replay end point based on the most recently received unconfirmed messages in the local communication terminal; filtering the messages in the buffer queue based on the replay start point and the replay end point to obtain the replay message queue.

[0044] In this embodiment of the application, the session metadata of the local communication end and the peer communication end are first checked for consistency. When the session identifier of the local communication end and the session identifier of the peer communication end are completely matched, and the session snapshot identifier of the local communication end and the session snapshot identifier of the peer communication end are completely matched, it is determined that the local communication end and the peer communication end are currently in the same valid communication session, and the session context snapshot status of the two ends is consistent. The prerequisite for session recovery is met, and the subsequent message filtering and resending process can be entered to restore the session of the local communication end and the peer communication end.

[0045] If the session identifier does not match, it means that the communication link established between the local end and the peer end does not belong to the original historical session, and it belongs to a new session reconstruction scenario, so there is no need to restore the historical session. If the session identifier matches but the session snapshot identifier does not match, it means that the session context state of the two ends has changed and the historical session snapshots are inconsistent, the session progress cannot be continued, and recovery is not possible. When at least one of the session identifier and the session snapshot identifier does not match, the messages in the buffer queue are discarded, and no further operations for session recovery are performed. Session recovery is terminated directly to avoid resending error messages across sessions and across snapshot versions.

[0046] When the session identifier and session snapshot identifier match, the replay interval is defined, which determines the replay start and end points. Messages whose sequence numbers fall within the replay interval are added to the replay message queue and retransmitted. The replay start point is determined based on the most recent consecutive messages, and the replay end point is determined based on the most recent message in the buffer queue that has not yet received an acknowledgment message from the communication peer.

[0047] If the sequence number of the most recently received consecutive message that has been confirmed received at the communication peer is the first sequence number m, and the sequence number of the most recently received message that has not been confirmed received at the communication local end is the second sequence number n, then the replay interval is (m, n).

[0048] Session snapshot and session management modules are deployed on both the local and remote ends of the communication system.

[0049] The session snapshot module generates and saves session snapshots when preset trigger conditions are met. Session snapshots record key context parameters required for session recovery. These parameters mainly include the session identifier, snapshot identifier, sequence numbers of acknowledged messages, sequence number ranges of unacknowledged messages, and buffer queue pointer information. After detecting the preset trigger conditions, the session snapshot module collects the session execution parameters at the current moment, generates, and stores the session snapshot.

[0050] A session snapshot is triggered when at least one of the following conditions is met: a fixed time period is reached; the water level advance exceeds a preset step size; a high-priority event is sent; an abnormality in the communication link is detected; or the application is hibernating, restarting, or upgrading.

[0051] The confirmation level is the sequence number position of the most recently received consecutive messages that the communication peer has confirmed. It is used to characterize the current message reception progress of the session. The confirmation level advances beyond the preset step size, which means that the difference in the sequence number of the most recently received consecutive messages exceeds the preset step size. For example, the preset step size is 20 messages. After each message is confirmed, the confirmation level is updated in real time. When the confirmation level advances from sequence number 100 to 121, the advance value exceeds 20, and a session snapshot is triggered.

[0052] The session snapshot includes at least one of the following fields: session identifier, peer node identifier, snapshot version number, most recent snapshot timestamp, most recently acknowledged send sequence number, most recently acknowledged receive sequence number, description of unacknowledged message range, summary of recently processed message identifier set, priority header pointer, event chain index, etc.

[0053] In this embodiment of the application, the message sequence number is a sequential number assigned to each message to be sent by the local communication terminal according to a preset sending order. The sequence numbers of each message are incremented sequentially, serving as a message sending time sequence marker.

[0054] Preferably, the session snapshot adopts a lightweight recording method, saving only the key parameters needed for session recovery, rather than copying the entire message body, in order to reduce the storage and computing burden.

[0055] For high-priority messages that have not yet received acknowledgment, the index position, event identifier, and priority identifier of the high-priority message are additionally recorded in the session snapshot so that they can be processed first when the session resumes.

[0056] In another optional embodiment, the messages in the buffer queue are filtered based on the replay start point and the replay end point, including: filtering out messages in the buffer queue that fall between the replay start point and the replay end point to obtain an initial message queue; and filtering the messages in the initial message queue based on the preset maximum number of messages in the replay message queue and the priority level of each message in the initial message queue to obtain the replay message queue.

[0057] In this embodiment of the application, the number of messages in the replay message queue is limited, that is, it does not exceed the preset maximum number of messages. By limiting the number of messages in the replay message queue, the excessive number of messages that need to be resent is avoided, which would cause communication link congestion when the session is restored.

[0058] Each message in the initial message queue has a corresponding priority level. Messages are filtered and sorted from highest to lowest priority level. Messages with higher priority levels are added to the replay message queue first. Once the number of messages in the replay message queue exceeds the preset maximum number of messages, the remaining messages with lower priority levels can be discarded or wait for the next replay scheduling.

[0059] Session metadata may also include session identifier, previous session mapping identifier, most recent snapshot version, most recently confirmed send sequence number, most recently confirmed receive sequence number, local unconfirmed interval, most recently processed message timestamp, and local recovery start time. The two communicating ends exchange each other's session metadata to determine whether it is a recovery of the original session, whether session recovery business needs to be performed based on a specified snapshot version, whether messages in the buffer queue have been confirmed and do not need to be resent, filter unconfirmed messages that are included in the replay message queue, and at the same time determine whether the current recovery time has exceeded the recovery latency threshold.

[0060] Step S13: Send the message in the replay message queue to the communication peer to restore the session between the local communication terminal and the communication peer.

[0061] In this embodiment of the application, after filtering the messages in the buffer queue to obtain the replay message queue, the messages in the replay message queue are sent to the communication peer to gradually restore the interrupted session between the local communication end and the communication peer.

[0062] In an optional embodiment, sending messages from the replay message queue to the communication peer includes: dividing the replay message queue into multiple message sub-queues based on priority levels, wherein messages in each message sub-queue have the same priority level and are arranged in ascending order of sequence number; traversing all message sub-queues in descending order of priority level, and sending messages in the currently traversed message sub-queue in ascending order of sequence number each time a message sub-queue is traversed.

[0063] In this embodiment of the application, messages in the replay message queue are grouped according to the priority level of each message to generate multiple message sub-queues; each message sub-queue stores messages with the same priority level, and the sub-queues are sorted in ascending order of message sequence number.

[0064] During the message sending phase, all message subqueues are traversed in descending order of priority. Each time a message subqueue is traversed, all messages in that subqueue are sent in ascending order of sequence number.

[0065] When messages in the same event chain are assigned the same priority, all messages in the same event chain are stored in the same message sub-queue and sorted in ascending order of message sequence number, so that messages in the same event chain maintain causal order in the message sub-queue.

[0066] By traversing all message subqueues in descending order of priority, high-priority messages are sent first, and then low-priority messages such as status messages are sent gradually, thus avoiding the blocking of high-priority message sending by a large number of low-priority messages.

[0067] In an optional embodiment, the session recovery method further includes: receiving a recovery message sent by the communication peer in response to the recovery of the communication link; performing service deduplication verification on the recovery message; and determining whether to process the recovery message based on the verification result.

[0068] In this embodiment of the application, in addition to sending a message to be restored to the communication peer, the local communication terminal also receives a restoration message sent by the communication peer. After receiving the restoration message, it needs to perform business processing based on the restoration message.

[0069] Taking the local communication end as a cloud server and the communication peer as a smart camera as an example, the cloud receives various messages cached during the communication link anomaly sent by the smart camera, namely recovery messages. The recovery messages need to be processed, that is, the business payload carried by the recovery message is parsed, and the corresponding upper-layer application actions are executed according to the device events, status information and media data in the payload. For example, the upper-layer application action saves the video clip in the cloud and associates it with the event.

[0070] Before processing the business, the recovery message is first deduplicated. If the validation result is successful, the recovery message is processed to avoid the same message triggering business processing repeatedly.

[0071] The process of performing service deduplication verification on the recovery message and determining whether to process the recovery message based on the verification result includes: comparing the current sequence number of the recovery message with the expected sequence number; if the current sequence number is greater than the expected sequence number, determining that the recovery message is an early arrival message, caching the recovery message in the pending message set, and processing the recovery message based on the recovery message when all messages between the expected sequence number and the current sequence number are received; if the current sequence number is less than the expected sequence number and falls within a preset receiving window, determining whether the recovery message is a duplicate message; and if the recovery message is not a duplicate message, processing the recovery message based on the recovery message.

[0072] In this embodiment of the application, when performing deduplication verification on the recovery message, the sequence number of the currently received recovery message (denoted as the current sequence number) is first compared with the expected sequence number. The expected sequence number is the sequence number of the next message expected to be received by the local communication terminal. After each message is successfully processed, the expected sequence number is incremented by 1.

[0073] In some transmission scenarios, recovery messages may arrive out of order. Messages in the replay message queue may be delivered via different network transmission paths. Some messages arrive at the local end of the communication first, forming ahead-arriving messages, while others arrive late due to transmission delays.

[0074] When the current sequence number is greater than the expected sequence number, it indicates that the recovery message is an advanced message. The message corresponding to the preceding sequence number of the recovery message has not yet arrived at the local communication terminal. Since messages in the same event chain have a causal order, the business processing of the subsequent message cannot be performed first. Therefore, the recovery message is cached in the message set to be processed, and the processing of the recovery message is performed after the message corresponding to the preceding sequence number of the recovery message is completed. This avoids causal reversal and prevents the timing of events reported by the smart camera from being disordered.

[0075] When the current sequence number is less than the expected sequence number, it indicates that the recovery message is a delayed message. When the session is restored, the communication peer may repeatedly send part of the message, resulting in a delayed message.

[0076] If a recovery message that is determined to be a delayed message does not fall into the preset receiving window, the recovery message is considered an outdated message that has timed out and will be discarded without further processing.

[0077] If a recovery message identified as a delayed message falls into the preset receiving window, it is necessary to determine whether the recovery message is a duplicate message, that is, whether the recovery message is the same as a historical message that has already been processed. If the recovery message is a duplicate message, it is discarded directly without processing. If the recovery message is not a duplicate message, it is processed.

[0078] Further, determining whether the recovery message is a duplicate message includes: determining whether the message identifier of the recovery message is the same as the message identifier of the processed message within a preset time window; if yes, determining that the recovery message is a duplicate message; if no, determining whether it is a duplicate message based on the timestamp of the recovery message and the timestamp of the historical message.

[0079] In this embodiment of the application, when determining whether a recovery message is a duplicate message, the message identifier of the current recovery message is compared with the message identifiers corresponding to all messages that have completed business processing within a preset time window. If there are identical message identifiers within the preset time window, the recovery message is directly determined to be a duplicate message, and the business processing is abandoned. If there are no identical message identifiers within the preset time window, the timestamp carried by the recovery message is retrieved and compared with the timestamps of historical messages. If there is a historical message whose timestamp is close to the timestamp carried by the recovery message, then the recovery message is a duplicate message.

[0080] Even without performing any business processing, the received recovery message will still generate a corresponding confirmation message and send it back to the corresponding communication peer.

[0081] After successfully processing the recovery message at the local end of the communication, an acknowledgment message is returned to the peer end. The acknowledgment message includes: the sequence number of the most recent consecutive message received; the list or range of missing sequence numbers that have been filled in; the duplicate message identifier; the event chain commit status; and a deduplication window information summary.

[0082] Upon receiving confirmation information, the peer updates the confirmation level, the set of unconfirmed messages, the head pointer of the buffer queue, the session snapshot, and the session state.

[0083] Once all messages in the replay message queues of both the peer and local communication terminals have been confirmed in a closed loop, the system enters the recovery completion state.

[0084] In another optional embodiment, the session recovery method further includes: recording the duration of the communication link anomaly; when the duration exceeds a preset latency threshold, executing at least one of the following degradation strategies: discarding messages to be recovered with a preset priority, generating an event continuity interruption flag, triggering an anomaly warning message at the local communication end and saving a complete video recording at the local communication end, re-establishing a new session with a recovery failure flag, requesting manual intervention, or requesting an event summary from a cloud event storage platform.

[0085] In this embodiment, a timer is started when an anomaly is detected in the communication link. If the link fails to successfully restore the session within the maximum recovery delay threshold, the indefinite session recovery wait is terminated, and a corresponding degradation strategy is initiated. The degradation strategy specifically includes at least one of the following handling methods: discarding messages awaiting recovery with a preset priority, generating an event continuity interruption flag, triggering an anomaly warning message at the local communication end and saving a complete recording at the local communication end, re-establishing a new session with a recovery failure flag, requesting manual intervention, or requesting an event summary from a cloud-based event storage platform.

[0086] Among them, messages awaiting recovery that are discarded with preset priorities include low-priority messages such as ordinary timed snapshots and routine status reports, in order to reduce transmission load and prioritize the recovery of core services.

[0087] An event continuity interruption flag is generated to indicate that the session recovery timeout or some event messages are lost. The cloud determines that there is a gap in the event chain based on the event continuity interruption flag and will not report complete data by default, so that upper-layer programs can make adaptation processing.

[0088] An abnormal warning message is triggered at the local communication terminal, and the complete video recording is saved at the local communication terminal to avoid the loss of monitoring video recordings due to network failures, thus ensuring the backup storage of security data.

[0089] A new session is re-established with a recovery failure flag, old sessions that have been recovered for a long time are discarded, and a brand new session channel is built. The reason for the recovery failure is included with the connection request, so that the cloud can know the background of the failure and optimize the subsequent message scheduling scheme.

[0090] Request manual intervention and request event summaries from the cloud event storage platform. When the session recovery strategy fails, it switches to manual handling mode. The upper-layer cloud retrieves concise key event summaries, eliminating the need to transmit massive amounts of complete messages and reducing data transmission pressure.

[0091] In addition, when creating a session, the communication end performs initialization work on various operating parameters. The initialization parameters include session identifier, bidirectional transmission sequence number and reception sequence number of the local communication end and the communication peer end, session status, heartbeat parameters, number of acknowledgment message timeouts, replay message queue, maximum recovery delay threshold, and priority level corresponding to various message types.

[0092] The session state is divided into several operating modes, namely the session initialization state, the stable transmission state of the communication link, the state of the communication link performance deterioration but not yet disconnected, the buffer state of the service message being stored in the buffer queue, the negotiation state of the session recovery negotiation, the state of retransmitting unacknowledged messages, the state of the session recovery completed and the state submission completed, and the session recovery failure state.

[0093] Please see Figure 2 , Figure 2 This is a schematic diagram of the architecture of the session recovery system provided in this application.

[0094] like Figure 2 As shown, the session recovery system includes a session management module, a link detection module, a buffer queue module, a recovery negotiation module, a latency constraint module, a message replay module, a deduplication verification module, a closed-loop confirmation module, and a session snapshot module.

[0095] The session management module is used to establish sessions, maintain session state machines, allocate or record session identifiers, maintain bidirectional sequence numbers and acknowledgment levels at the communication ends, and control the switching of sessions between states such as initialization, stable transmission, link degradation, recovery negotiation, replay and retransmission, and recovery completion.

[0096] After detecting the preset trigger conditions, the session snapshot module collects the session running parameters at the current moment, generates and stores a session snapshot.

[0097] The link detection module monitors at least one of the following anomaly indicators of the communication link: number of consecutive heartbeat timeouts, number of times acknowledgment messages are not returned, average latency and jitter amplitude, packet loss rate, number of reconnections, session failure rate, and sudden changes in wireless signal strength.

[0098] When the buffer queue module detects an anomaly in the communication link, it triggers message caching processing, storing all messages awaiting subsequent resending into the buffer queue on the local end of the communication. The buffer queue stores messages that have not yet been successfully sent to the other end of the communication.

[0099] The recovery negotiation module is used to exchange session metadata with the communication peer after the communication link is restored, and to determine the replay start point and replay message queue based on the session metadata.

[0100] The message replay module resends messages in the replay message queue in order, and performs bounded replay and priority scheduling by combining message priority, event chain causal order and window limit.

[0101] The deduplication verification module performs deduplication verification when receiving recovery messages. For example, it identifies duplicate messages, out-of-order messages, and missing messages based on sequence numbers, time windows, message identifiers, and event identifiers, and performs idempotent processing on duplicate messages to avoid duplicate alarms, duplicate command executions, and duplicate indexes.

[0102] The closed-loop confirmation module is used to generate confirmation information for recovered messages, update the confirmation level, submit the event chain status, and trigger snapshot updates, thereby enabling the resent messages to complete business-level closed-loop confirmation.

[0103] The latency constraint module is used to time the session recovery process, monitor the duration from the detection of communication link anomaly to the completion of recovery loop, and trigger degraded recovery, partial recovery, local fallback alarm or new session reconstruction strategy when the maximum recovery latency threshold is exceeded.

[0104] Taking an IoT distribution system based on smart cameras as an example, the IoT distribution system includes: camera terminal nodes, home hub nodes, and cloud nodes and mobile terminal nodes that can be configured on demand. The home hub nodes are preferably deployed on home gateway devices or their built-in logical function modules.

[0105] As the event initiating side, the camera terminal node mainly undertakes functions such as session maintenance, communication link anomaly detection, pending confirmation message caching, and local backup recovery. The home hub node mainly undertakes functions such as local area network collaborative communication, response receipt generation, data aggregation and forwarding, and multi-device status summary. The cloud node is responsible for message reception, content verification, persistent log storage, and issuing various cloud control commands. The mobile terminal node is only used to receive alarms, receive user confirmation commands, and generate simple receipts, and is not used as the core execution unit for session failure recovery.

[0106] like Figure 2 The modules shown can be centrally deployed in the same device or distributed across multiple nodes. Preferably, the camera terminal node deploys a session management module, a session snapshot module, a link detection module, a buffer queue module, a recovery negotiation module, a message replay module, a closed-loop confirmation module, and a latency constraint module; the home hub node deploys a session management module, a link detection module, a recovery negotiation module, a deduplication verification module, and a closed-loop confirmation module, and optionally deploys a buffer queue module and a message replay module; the cloud node deploys a session management module, a recovery negotiation module, a deduplication verification module, and a closed-loop confirmation module, and also deploys a log retention module; the mobile terminal node preferably deploys a session management module, a link detection module, a deduplication verification module, and a confirmation receipt module.

[0107] Please see Figure 3 , Figure 3 This is a schematic diagram of the session recovery process in another embodiment provided in this application, such as... Figure 3 As shown, a session state machine is established and session parameters are initialized; in a stable transmission state, session snapshots are periodically created; the quality of the communication link is monitored in real time; it is determined whether the communication link is abnormal; when the communication link is abnormal, message caching is triggered, and all messages waiting to be resent are stored in the buffer queue of the local communication end; after the communication link is restored, session metadata is exchanged with the communication peer; the replay starting point and replay message queue are determined according to the session metadata; the messages in the replay message queue are resent in order; the receiving end performs deduplication verification on the received recovery messages; the receiving end returns confirmation information and updates the session snapshot; it is determined whether the session recovery is completed within the maximum recovery delay threshold. If not, a degradation strategy is executed; if so, the session recovery is determined to be complete and the system returns to a stable transmission state.

[0108] Through the above embodiments, when the communication link between the local end and the peer end is abnormal, the message to be restored is stored in a buffer queue to cache messages that were not successfully sent to the peer end due to the communication link failure, thus avoiding message loss. After the communication link is restored, the session metadata of the local end and the peer end are exchanged, and the replay message queue is filtered based on the most recent consecutive messages that the peer end has confirmed to receive, thus avoiding duplicate message sending. By sending messages in the replay message queue, message loss is avoided when the session is restored, ensuring the continuity and integrity of events in the session.

[0109] To implement the above-mentioned session recovery method, this application also proposes a session recovery device, which can be found in the following details. Figure 4 , Figure 4 This is a schematic diagram of an embodiment of the session recovery device provided in this application.

[0110] The session recovery device 400 in this embodiment includes a processor 41, a memory 42, an input / output device 43, and a bus 44.

[0111] The processor 41, memory 42, and input / output device 43 are respectively connected to the bus 44. The memory 42 stores program data, and the processor 41 is used to execute the program data to implement the session recovery method described in the above embodiments.

[0112] In this embodiment, processor 41 can also be referred to as a CPU (Central Processing Unit). Processor 41 may be an integrated circuit chip with signal processing capabilities. Processor 41 can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor, or processor 41 can be any conventional processor.

[0113] This application also provides a computer storage medium; please refer to the following: Figure 5 , Figure 5 This is a schematic diagram of a computer storage medium 500 according to an embodiment of the present application. The computer storage medium 500 stores a computer program 51, which, when executed by a processor, is used to implement the session recovery method of the above embodiment.

[0114] When the embodiments of this application are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0115] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A session recovery method, characterized in that, The session recovery method includes: In response to an anomaly in the communication link between the local communication terminal and the peer communication terminal, messages to be recovered are added to the buffer queue of the local communication terminal. The buffer queue is used to store messages that the local communication terminal failed to send to the peer communication terminal. In response to the restoration of the communication link, the messages in the buffer queue are filtered based on the session metadata of the local communication terminal and the session metadata of the peer communication terminal to obtain a replay message queue. The sending order of the messages in the replay message queue is no earlier than the sending order of the most recent consecutive messages. The most recent consecutive message is the last message among multiple consecutive messages that the peer communication terminal has confirmed to have received. Send the message in the replay message queue to the communication peer to resume the session between the communication local end and the communication peer.

2. The session recovery method according to claim 1, characterized in that, The session metadata includes a session identifier and a session snapshot identifier; Based on the session metadata of the local communication endpoint and the session metadata of the peer communication endpoint, messages in the buffer queue are filtered to obtain a replay message queue, including: In response to the session identifier of the local communication terminal matching the session identifier of the peer communication terminal, and the session snapshot identifier of the local communication terminal matching the session snapshot identifier of the peer communication terminal, the replay start point is determined based on the most recent consecutive messages that have been confirmed received in the peer communication terminal, and the replay end point is determined based on the most recent unconfirmed messages that have been received in the local communication terminal. The messages in the buffer queue are filtered based on the replay start point and the replay end point to obtain the replay message queue.

3. The session recovery method according to claim 2, characterized in that, Messages in the buffer queue are filtered based on the replay start point and the replay end point, including: Messages that fall between the replay start point and the replay end point in the buffer queue are filtered out to obtain the initial message queue; Based on the preset maximum number of messages in the replay message queue and the priority level of each message in the initial message queue, the messages in the initial message queue are filtered to obtain the replay message queue.

4. The session recovery method according to claim 1, characterized in that, Sending the messages in the replay message queue to the communication peer includes: The replay message queue is divided into multiple message sub-queues based on priority levels, wherein the messages in each message sub-queue have the same priority level and are arranged in ascending order of sequence number. The message subqueues are traversed in descending order of priority. Each time a message subqueue is reached, the messages in the currently visited message subqueue are sent in ascending order of sequence number.

5. The session recovery method according to claim 4, characterized in that, The session recovery method further includes: In response to the restoration of the communication link, receive a recovery message sent by the communication peer; The recovery message is subjected to business deduplication verification, and the verification result is used to determine whether to process the recovery message.

6. The session recovery method according to claim 5, characterized in that, Perform service deduplication verification on the recovery message, and determine whether to process the recovery message based on the verification result, including: Compare the current sequence number of the recovery message with the expected sequence number; When the current sequence number is greater than the expected sequence number, the recovery message is determined to be an early arrival message. The recovery message is cached in the message set to be processed until all messages between the expected sequence number and the current sequence number are received. Then, business processing is performed based on the recovery message. When the current sequence number is less than the expected sequence number and falls within the preset receiving window, it is determined whether the recovery message is a duplicate message; When the recovery message is not a duplicate message, business processing is performed based on the recovery message.

7. The session recovery method according to claim 6, characterized in that, Determining whether the recovery message is a duplicate message includes: Determine whether the message identifier of the recovery message is the same as the message identifier of the processed message within a preset time window; If so, determine that the recovery message is a duplicate message; If not, determine whether it is a duplicate message based on the timestamp of the recovery message and the timestamp of the historical message.

8. The session recovery method according to claim 1, characterized in that, The session recovery method further includes: Record the duration of the communication link anomaly; When the duration exceeds a preset latency threshold, execute at least one of the following degradation strategies: discard messages to be recovered with a preset priority, generate an event continuity interruption flag, trigger an abnormal warning message on the local communication end and save a complete recording on the local communication end, re-establish a new session with a recovery failure flag, request manual intervention, or request an event summary from the cloud event storage platform.

9. A session recovery device, characterized in that, The session recovery device includes a memory and a processor coupled to the memory; The memory is used to store program data, and the processor is used to execute the program data to implement the session recovery method as described in any one of claims 1 to 8.

10. A computer storage medium, characterized in that, The computer storage medium is used to store program data, which, when executed by the computer, is used to implement the session recovery method as described in any one of claims 1 to 8.

Images