Link switching method and system, computer equipment and storage medium

Abstract

The invention relates to a link switching method and system, computer equipment and a storage medium. The link switching method and system are realized on the basis of virtualized Socket layers deployed on a main control side and a module side of an OpenCPU heterogeneous system. The method comprises the following steps: in response to a migration triggering condition, initiating a migration request of a network session between a master control side and a module side; generating a session state of the network session at a source end currently holding the network session, and transmitting the session state subjected to serialization processing to a target end; and at the target end, based on the received session state, recovering and taking over the network session. According to the application, the virtualization Socket layers are deployed on the master control side and the module side, and serialization and synchronization of session states of the master control side and the module side are realized by the virtualization Socket layers, so that communication continuity of network sessions is ensured, and the problem that lossless link switching between the master control side and the module cannot be realized is solved.

Description

Technical Field

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

[0002] With the rapid development of IoT technology, higher demands are being placed on the intelligence, low power consumption, and always-on connectivity of terminal devices. Against this backdrop, a heterogeneous dual-system architecture of "main controller + communication module" has become the mainstream design for many complex IoT devices (such as smart cameras and vehicle terminals). Among these, OpenCPU, as an advanced development model, reduces the main controller wake-up time and transfers keep-alive functions to the module, thereby improving the device's energy efficiency and extending battery life.

[0003] When implementing efficient energy management, existing heterogeneous systems based on OpenCPU face challenges in communication modules acquiring and taking over the complex session states of the master control side. This requires synchronizing complex network state machines (such as TCP states, sequence numbers, retransmission timers, etc.), which can easily lead to state asynchrony during the switching process, resulting in session interruptions and unstable data transmission. Consequently, lossless link switching between the master control and modules cannot be achieved.

[0004] There is currently no effective solution to the problem that related technologies cannot achieve lossless link switching between the main control unit and the module. Summary of the Invention

[0005] Therefore, it is necessary to provide a link switching method, system, computer equipment, and storage medium that enables lossless switching between the main controller and modules to address the aforementioned technical problems.

[0006] Firstly, this embodiment provides a link switching method, implemented based on a virtualized Socket layer deployed on the master control side and module side of an OpenCPU heterogeneous system; the method includes:

[0007] In response to the migration triggering condition, a migration request for a network session is initiated between the main control side and the module side;

[0008] At the source end currently holding the network session, a session state of the network session is generated, and the serialized session state is transmitted to the target end; wherein, the source end is the master control side, and the target end is the module side; or, the source end is the module side, and the target end is the master control side.

[0009] At the target end, based on the received session state, the network session is restored and taken over.

[0010] In some embodiments, initiating a network session migration request between the master control side and the module side in response to a migration triggering condition includes:

[0011] When the master control side enters sleep mode, the master control side initiates a migration request to migrate the network session to the module side;

[0012] When the master control side is woken up, it initiates a migration request to migrate the network session to the master control side.

[0013] In some embodiments, generating the session state of the network session and transmitting the serialized session state to the target end includes:

[0014] Based on the PCB, buffer metadata, and the communication protocol type of the network session, the session state of the network session is generated; the session state includes the session state of the master control side at the time of freezing, or the session state generated by the module side during takeover.

[0015] The session state is serialized and transmitted to the target end through the transmission channel between the main control side and the module side.

[0016] In some embodiments, generating the session state of the network session based on the PCB, buffer metadata, and the communication protocol type of the network session includes:

[0017] Based on the communication protocol type, determine the corresponding migration data item;

[0018] Based on the migration data items, the corresponding fields are extracted from the PCB and the buffer metadata to generate the session state.

[0019] In some embodiments, the step of serializing the session state and transmitting it to the target end through the transmission channel between the master control side and the module side includes:

[0020] The session state is serialized into binary format, and a version number, timestamp, and checksum are appended to the serialization header to generate a serialized session state.

[0021] The serialized session state is transmitted to the target end via shared memory or a built-in control channel.

[0022] In some embodiments, the step of resuming and taking over the network session based on the received session state includes:

[0023] By deserializing the session state, the context of the network session is reconstructed to recover and take over the network session.

[0024] In some embodiments, after the target end takes over the network session, the method further includes:

[0025] In response to the migration triggering condition, a migration request for a network session is initiated between the main control side and the module side;

[0026] At the source end currently holding the network session, the session state of the network session is generated, and the serialized session state is transmitted to the target end;

[0027] At the target end, based on the received session state, the network session is restored and taken over.

[0028] Secondly, this embodiment provides a link switching system applicable to the link switching method described in the first aspect above.

[0029] Thirdly, this embodiment provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the link switching method described in the first aspect above.

[0030] Fourthly, this embodiment provides a storage medium storing a computer program that, when executed by a processor, implements the link switching method described in the first aspect above.

[0031] Compared with related technologies, the link switching method, system, computer device, and storage medium provided in this embodiment are implemented based on a virtualized Socket layer deployed on the master control side and module side of an OpenCPU heterogeneous system. In response to a migration trigger condition, a network session migration request is initiated between the master control side and the module side. At the source end currently holding the network session, a session state of the network session is generated, and the serialized session state is transmitted to the target end. Wherein, the source end is the master control side, and the target end is the module side; or, the source end is the module side, and the target end is the master control side. At the target end, based on the received session state, the network session is restored and taken over. By deploying a virtualized Socket layer on the master control side and module side in this embodiment, and using the virtualized Socket layer to serialize and synchronize the session states of the master control side and module side, the communication continuity of the network session is guaranteed, solving the problem of the inability to achieve lossless link switching between the master control side and the module.

[0032] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0033] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0034] Figure 1 This is a hardware structure block diagram of the terminal of the link switching method in one embodiment;

[0035] Figure 2 This is a schematic diagram of the architecture of an OpenCPU heterogeneous system in one embodiment;

[0036] Figure 3 This is a flowchart of a link switching method in one embodiment;

[0037] Figure 4 This is a schematic diagram of the process of a module taking over a network session in one embodiment;

[0038] Figure 5 This is a schematic diagram of the process of restoring a network session on the master control side in one embodiment.

[0039] In the diagram: 102, processor; 104, memory; 106, transmission device; 108, input / output device. Detailed Implementation

[0040] To better understand the purpose, technical solution, and advantages of this application, the application is described and illustrated below in conjunction with the accompanying drawings and embodiments.

[0041] Unless otherwise defined, the technical or scientific terms used in this application shall have the general meaning understood by one of ordinary skill in the art to which this application pertains. Words such as “a,” “an,” “an,” “the,” “the,” and “these” used in this application do not indicate quantitative limitation and may be singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that comprises a series of steps or modules (units) is not limited to the listed steps or modules (units) but may include steps or modules (units) not listed, or may include other steps or modules (units) inherent to these processes, methods, products, or devices. Words such as “connected,” “linked,” and “coupled” used in this application are not limited to physical or mechanical connections but may include electrical connections, whether direct or indirect. “Multiple” used in this application refers to two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. Normally, the character " / " indicates that the objects before and after it are in an "or" relationship. The terms "first," "second," "third," etc., used in this application are merely to distinguish similar objects and do not represent a specific order of objects.

[0042] The method embodiments provided in this example can be executed on a terminal, computer, or similar computing device. For example, it can run on a terminal. Figure 1 This is a hardware structure block diagram of the terminal in the link switching method of this embodiment. For example... Figure 1 As shown, a terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 and a memory 104 for storing data are also included. The processor 102 may be, but is not limited to, a microprocessor (MCU) or a programmable logic device (FPGA). The terminal may also include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that… Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the terminal described above. For example, the terminal may also include components that are larger than... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown are illustrated.

[0043] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the link switching method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0044] The transmission device 106 is used to receive or send data via a network. This network includes a wireless network provided by the terminal's communication provider. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 can be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0045] This application aims to address issues such as session interruption, port conflicts, and unreliable connections caused by main controller sleep or link instability in low-power operating environments for IoT devices (such as cameras), particularly targeting the following typical technical challenges:

[0046] Master-module connection state management is complex and fragile: Existing practices based on the OpenCPU architecture often require synchronizing complex network state machines (such as TCP states, sequence numbers, retransmission timers, etc.) during link switching or master / module responsibility switching. Due to context switching, asynchronous interruption, and resource constraints between the master and module, state desynchronization can easily occur during the switching process, leading to session interruption (e.g., TCP connection timeout, application layer reconnection failure, or packet out-of-order delivery).

[0047] Port resource conflicts and platform awareness confusion: Some communication modules use fixed source ports or port reuse strategies for network data distribution between the main control unit and the module. When the device reconnects abnormally or establishes a large number of sessions in a short period of time, it will trigger the exhaustion of the NAT gateway or the operator's mapping table, resulting in problems such as out-of-order mapping, connection session confusion or rejection, which seriously affects the stability of data transmission.

[0048] In low-power scenarios, master-slave link switching incurs significant overhead: existing link switching schemes require complex protocol stack state synchronization and reconstruction operations during the switching process, forcing the main control module to exit the low-power state and extending the active duration of the communication module. In battery-powered scenarios, such operations constitute a significant energy consumption bottleneck: even if the device has a controllable wake-up strategy, the overhead of state synchronization and reconstruction still severely restricts the long-term deployment and stable operation of lightweight applications based on OpenCPU, which contradicts the low-power goal of the OpenCPU framework.

[0049] This embodiment provides a link switching method, which is implemented based on the virtualized Socket layer (virtual socket core layer) deployed on the master control side and module side of the OpenCPU heterogeneous system.

[0050] Figure 2 This is a schematic diagram of the architecture of the OpenCPU heterogeneous system in this embodiment, as shown below. Figure 2 As shown, the OpenCPU heterogeneous system is a software development architecture that allows developers to run custom application code directly on the CPU inside a communication module (e.g., 4G Cat.1, NB-IoT, 5G module). In this architecture, the communication module is no longer just a "black box" responsible for sending and receiving data, but becomes a "microcomputer" integrating communication functions and computing capabilities. In this embodiment, the module side refers to the communication module itself and its internal operating environment, whose operating system includes, but is not limited to, RTOS; the main control side refers to the external, independent central processing unit in the system, which mainly handles complex computational tasks that the module side is not good at or cannot complete (such as complex image processing, audio processing, and a large number of floating-point operations), as well as controlling and connecting more complex or numerous peripherals that the module does not support (such as high-definition displays, cameras, multi-channel motor drives, complex touchscreens, etc.), and whose operating system includes, but is not limited to, Linux. It should be noted that the operating systems of the main control side and the module side are not limited to a combination of Linux and RTOS.

[0051] VSocket Core (virtualized Socket layer) is a protocol-independent abstraction layer that exposes a unified Socket / Session API interface, allowing applications (application layer) to use this virtualization layer like a regular network connection, without needing to know whether the underlying connection is actually maintained by the Linux host or the RTOS module. It interfaces with and shields the implementation differences of the specific communication protocol stacks (such as TCP, UDP, QUIC) on both the host and module sides, directly connecting to the specific transmission implementation of the host or module. The host and module sides transmit physical packets encapsulated by the communication protocol stack over the Internet. The state synchronization engine and control channel are responsible for atomically migrating network sessions and connection layer states from the current session holder to the session takeover holder, and are designed to support state serialization / deserialization plugins or adapters for various transport protocols.

[0052] Figure 3 This is a flowchart of the link switching method in this embodiment, as follows: Figure 3 As shown, the method includes the following steps:

[0053] Step S301: In response to the migration triggering condition, a migration request for a network session is initiated between the master control side and the module side.

[0054] Specifically, in response to the migration triggering conditions, the migration process is triggered through the virtual socket core layer, and the master control side initiates a network session migration request to the module side.

[0055] Migration triggering conditions include two types: triggering master control sleep and triggering master control wake-up. On the one hand, the master control side can enter sleep mode to save energy through user manual operation, preset timer strategy, and specific event triggering. It can also be triggered by high-energy-consuming computing tasks such as AI image analysis and video processing to enter sleep mode and focus computing power. At this time, the master control side initiates a migration request to the module side to take over the network session. On the other hand, the master control side can be woken up by specific events, network events, etc. At this time, the master control side initiates a migration request to the module side to resume taking over the network session.

[0056] A network session is the core logical unit that maintains the continuity of communication between the device (master control side / module side) and external nodes (such as the cloud). It includes communication status information and business data association, and can be encapsulated as VSocket frames and managed through the virtualization Socket layer, and routed to the side that currently holds the session. In addition, the network session is also the core object of migration between the master control side and the module side.

[0057] The triggering conditions for the main control system to go into sleep mode include, but are not limited to: the user manually triggering the main control system to go into sleep mode through the camera's mobile app, web management backend, or local button; a preset timing strategy to automatically trigger the main control system to go into sleep mode during off-peak hours; the detection of specific events such as idle scenes by an unmanned object recognition algorithm to automatically trigger the main control system to go into sleep mode; and the planned execution of high-energy-consuming computing tasks to automatically trigger the main control system to go into sleep mode.

[0058] Triggering conditions for master control wake-up include, but are not limited to: users manually triggering master control wake-up through the camera's mobile app, web management backend, or local buttons; automatic master control wake-up when a human sensor (such as a passive infrared sensor PIR) detects a human body / object; and automatic master control wake-up when the module receives network events such as network communication requests from the cloud.

[0059] Step S302: At the source end that currently holds the network session, generate the session state of the network session and transmit the serialized session state to the target end; wherein, the source end is the master control side and the target end is the module side; or, the source end is the module side and the target end is the master control side.

[0060] Specifically, at the source end currently holding the network session, the state of the network session that needs to be maintained is frozen. Based on the communication protocol type, PCB (Protocol Control Block), etc., key fields in the PCB are extracted to generate the session state of the network session. Through the state synchronization engine, the session state is serialized and then securely transmitted to the module side through the shared memory area between the master control side and the module side, or through the built-in control channel.

[0061] In this scenario, when the source is the master control side and the target is the module side, the session state is briefly frozen on the master control side. This means pausing structural modifications to the PCB or recording change logs (incremental changes), and extracting key fields at the moment of freeze to generate the session state. Furthermore, the freeze window should be as short as possible to reduce network latency.

[0062] When the source is the module side, the target is the master control side. The session state maintained on the module side is frozen, and the key fields of the latest PCB generated by the module side during the takeover of the network session are extracted to generate the session state.

[0063] Step S303: At the target end, based on the received session state, the network session is restored and taken over.

[0064] Specifically, the target end uses a state synchronization engine to deserialize the received session state and restore the network session. When the target end is a module, after taking over the network session, the module reconstructs a semantically identical control block in its local protocol stack. Subsequently, the module's protocol stack takes over from the master control side and can independently maintain network heartbeats with the cloud, receive cloud commands, and even receive event pushes and process light data forwarding. At this time, the cloud only perceives a single logical connection online, without any switching awareness, and always considers the device to be online.

[0065] When the target device is the master control side, during network session recovery, the master control side deserializes and reconstructs the PCB context and application layer buffer association, restoring the communication protocol stack state. Subsequently, the master control side sends a takeover confirmation command to the module side, the module side stops session maintenance, and the master control side officially takes over the network session, quickly restoring services such as video streaming and PTZ control, achieving seamless switching and instantaneous recovery of network connectivity. From the user's perspective, the device's response speed from low-power sleep to waking up and completing complex operations such as video streaming and PTZ control is extremely fast, with almost no delay.

[0066] Through the above steps, a virtualized Socket layer is constructed between the master control side and the module side. This virtualized Socket layer synchronizes the session states of the master control side and the module side, ensuring the continuity of network session communication. It enables lossless hot migration and single logical connection maintenance of network sessions between the master control side and the module side, significantly reducing the risk of platform connection state-aware interruption. Furthermore, for the device side, lossless switching can be achieved through protocol-level session migration. Specifically, by migrating the session states at the protocol stack level (such as TCP control blocks and buffer states), zero-disconnection switching of the connection is achieved, thus ensuring session continuity. The source end can synchronize the state of unacknowledged data packets to the target end, ensuring the correct continuation of retransmission logic and preventing data loss. Moreover, it supports multiple protocols, can extend upper-layer protocols, and maintain session context. For the platform side, seamless switching can be achieved through system-level transparency and resource optimization. Specifically: the platform maintains only one external link: regardless of whether the master controller is in sleep mode, the platform always sees the same IP:Port 5-tuple connection, which will not trigger reconnection or session reconstruction; the platform does not need to be aware of the master controller / module switching logic inside the device, the link switching is completed entirely on the device side, and there is no need to handle frequent connection disconnection and reconstruction events, reducing the pressure on the platform's connection management module; furthermore, it avoids repeatedly establishing TCP connections and TLS secure channels; it reduces redundant traffic such as SYN packets, ACK packets, and certificate exchanges during the link establishment process; it saves connection tracking entries (conntrack) on gateway / NAT devices, improves overall network efficiency, and saves network resources.

[0067] In some embodiments, step S301 above, in response to a migration triggering condition, initiates a network session migration request between the master control side and the module side, including the following steps:

[0068] When the master control side enters sleep mode, it initiates a migration request to migrate the network session to the module side; when the master control side is woken up, it initiates a migration request to migrate the network session to the master control side.

[0069] Specifically, the master controller sleep mechanism: To reduce energy consumption, when there is no service load or the migration trigger conditions are met, the master controller of the IoT device shuts down non-core circuits, reduces its operating frequency, and enters a sleep state, retaining only necessary wake-up trigger channels (such as PIR sensor and module control signals). The master controller initiates a takeover request to the module side through the above trigger mechanism, which is also a migration request to migrate the network session to the module side.

[0070] Master control wake-up mechanism: It is divided into physical event wake-up (such as sensor triggering, button operation) and network event wake-up (such as cloud-based command sending, module receiving remote control signal). After wake-up, the master control quickly restores core functions and starts business processes. The master control side initiates a recovery request to the module side, which is also a migration request to migrate the network session to the master control side.

[0071] Using low-power IoT devices as the application platform, such as low-power cameras, which adopt the OpenCPU heterogeneous architecture described above, the following are some examples of migration triggering conditions:

[0072] Low power consumption strategy trigger scenario: The device is configured with a "no activity sleep" strategy. When the built-in image recognition algorithm does not detect any object movement in the monitored area for 10 consecutive minutes, the main controller determines that there is no current service load, starts the deep sleep process, and sends a network session migration request to the module side, and then enters the sleep state.

[0073] Triggering scenario for high-energy-consuming business preprocessing: When the device needs to perform AI face recognition (a high-energy-consuming task), in order to avoid excessive energy consumption due to the superposition of business operation and session maintenance, the main control side initiates a session migration request before starting face recognition. After the session is handed over to the module, the main control side runs the AI ​​algorithm at full capacity to improve processing efficiency.

[0074] Physical event wake-up trigger scenario: The device's PIR sensor detects human movement, generates a wake-up signal and sends it to the main control side. After the main control side starts up, it immediately initiates a session recovery migration request to the module side, requesting that the session be migrated back to the main control side to quickly restore the video surveillance service.

[0075] Network event wake-up trigger scenario: The cloud sends a remote voice call command to the device. After receiving the command, the module sends a wake-up signal to the master control side. After the master control side is woken up, it triggers a session migration request and takes over the session to handle voice call data transmission.

[0076] Through the migration triggering conditions and corresponding migration mechanisms in this embodiment, the session context is actively migrated to the module-side OpenCPU environment before the master control side goes into sleep mode. The module side independently maintains the long connection (such as heartbeat, push stream, etc.), which significantly reduces the frequency of master control wake-up and the dynamic power consumption of the whole machine. This allows the master control side to save energy when it goes into sleep mode and to recover quickly when it wakes up, thus meeting the low power consumption requirements and ensuring the real-time response of services.

[0077] In some embodiments, step S302, which generates the session state of the network session and transmits the serialized session state to the target end, includes the following steps:

[0078] Based on the PCB, buffer metadata, and the communication protocol type of the network session, the session state of the network session is generated. The session state includes the session state of the master control side at the time of freezing, or the session state generated by the module side during the takeover period. The session state is serialized and transmitted to the target end through the transmission channel between the master control side and the module side.

[0079] Specifically, the session state of the network session is constructed using the communication protocol's PCB as the core and combined with the buffer metadata of the application layer video stream. The source-side VSocket layer invokes a state synchronization engine, which first determines the communication protocol type of the network session to be migrated. Then, it accesses the kernel PCB data structure of the network session and queries relevant send / receive buffer metadata (such as a list of unacknowledged data segments). Next, based on the minimum migration data item determined by the communication protocol type, it extracts the corresponding fields from the PCB and buffer metadata and combines them to generate a complete session state. Finally, the session state is serialized into binary format and sent to the target end via a secure transmission channel (such as an SDIO-based internal bus, protected shared memory, or LAN communication).

[0080] The session state includes the session state of the master control side at the time of freezing, or the session state generated by the module side during the takeover period. When the master control side migrates the network session to the module side, the master control side will briefly freeze the session state, suspend structural modifications to the PCB or record change logs (incremental changes), and extract key fields at the time of freezing to generate the session state. At this time, the session state of the network session is the session state of the master control side at the time of freezing. When the module side migrates the network session to the master control side, the module side will generate the session state based on the latest key fields of the PCB generated during the takeover of the network session. At this time, the session state is the session state generated by the module side during the takeover period.

[0081] Because the complete transmission state cannot usually be transmitted during link switching, the target end needs to be reinitialized. This embodiment freezes the source protocol stack state and generates session state based on PCB and buffer metadata, ensuring the integrity and effectiveness of network session migration. This guarantees the semantic continuity of transport layer state, avoids performance degradation issues such as increased retransmission probability, congestion reset, and out-of-order data caused by multiple links, and fully restores the target protocol stack, ensuring semantic continuity of network behavior, avoiding restarts of flow control and congestion control, and effectively improving throughput and latency stability after switching. Simultaneously, serialization processing reduces data volume and provides a basis for data writing version verification.

[0082] In some embodiments, the process of generating the session state of the network session based on the PCB, buffer metadata, and the communication protocol type of the network session includes the following steps:

[0083] Based on the communication protocol type, determine the corresponding migration data item; based on the migration data item, extract the corresponding fields from the PCB and buffer metadata to generate the session state.

[0084] Specifically, by introducing a protocol adapter structure into the virtualized Socket layer, a unified migration abstraction for multiple communication protocols can be supported, featuring highly scalable and protocol-independent design. A necessary minimum state set is defined for different communication protocol types as migration data items. Through the corresponding protocol adapter, the fields corresponding to the migration data items are extracted from the PCB and buffer metadata to generate the session state. Typically, migration data items include key fields of the PCB (such as 5-tuples, sequence number, window size, state machine state, etc.) and metadata of the buffer (such as the buffer's starting sequence number, data length, etc.).

[0085] The following sections explain the process of determining migration data items and generating session states for three mainstream communication protocols: TCP (Transmission Control Protocol), UDP (User Datagram Protocol), and QUIC (Quick UDP Internet Connection).

[0086] Based on TCP connection-oriented sessions, migration data items should be included and limited to essential fields to reduce overhead. The following are migration data items based on TCP connection-oriented sessions:

[0087] (1) Local / remote IP address and port, current TCP state (e.g., ESTABLISHED);

[0088] (2) Send / receive sequence number (SND.NXT, RCV.NXT); Send / receive window (SND.WND, RCV.WND);

[0089] (3) Unconfirmed data queue metadata (offset, length, checksum or hash of each segment; the payload itself does not need to be copied, a reference handle can be used).

[0090] (4) Remaining time of the retransmission timer and the number of retransmissions; congestion control variables (cwnd, ssthresh);

[0091] (5) MSS and TCP options; metadata and mount point identifiers of application layer buffers;

[0092] (6) TLS session index or key handle (sensitive keys are not transmitted directly in plaintext; an HSM handle or reference can be used).

[0093] (7) Metadata: version number, timestamp, checksum / optional MAC.

[0094] Because UDP inherently lacks connectionless semantics, its network sessions are mostly maintained by upper-layer protocols or applications (e.g., implementations of RTP, DTLS, and QUIC when they are not in use). For UDP-based application protocols, it is preferable to perform "virtual port / egress mapping" on the device side to maintain continuous external network mapping, or to migrate the session ID and message sequence state to the module side, allowing the module side to continue the application protocol's acknowledgment and retransmission logic. The following are migration data items based on UDP connectionless sessions:

[0095] (1) Application session identifier (Session ID, sequence number / sliding window, message confirmation / retransmission queue metadata);

[0096] (2) Local / remote IP and port mapping (ensure that the module can maintain or rebuild NAT mapping after takeover);

[0097] (3) Unsent or unacknowledged data buffers (offset / length / handle);

[0098] (4) Application-level retransmission or ACK semantic state (e.g., RTP sequence number, SRTP key handle / index, DTLS session handle).

[0099] QUIC combines transport and encryption, possessing its own Connection ID, Packet Number, TLS-derived keys, stream layer semantics, connection loss detection, and congestion control. During migration, the QUIC Connection ID policy should be preserved, with Connection IDs mapped and managed uniformly on the device side to prevent server-side connection drops due to port / IP changes. The migration data items for QUIC sessions are:

[0100] (1) Identification and metadata: Connection ID(s), version, remote / local CID mapping;

[0101] (2) Encryption status: TLS 1.3 derived key material (key suite, AEAD key, IVs, key update count, key derivation context), and employing HSM handle, key encapsulation or restricted export strategy;

[0102] (3) Packet / flow control: highest sent packet number (largest_sent), highest acknowledged packet number (largest_acked), packet_number spaces (Initial / Handshake / Application), bytes_in_flight, and stream status (offset / window / status of each stream).

[0103] (4) Loss detection and RTT: status related to rtt estimator, pto / timeout value, and retransmission timing;

[0104] (5) Connection parameters: transport parameters, maximum concurrent flow, maximum data, etc.

[0105] Existing solutions are typically bound to specific protocols and rely on built-in protocol mechanisms for switching, lacking a universal state transition framework across communication protocols. This embodiment introduces a protocol adapter structure at the VSocket layer, defining necessary minimum state sets and recovery processes for different communication protocol types to achieve cross-protocol universality, improve system scalability, and further avoid the link switching overhead of dual-link architecture under OpenCPU, reducing platform management costs and mitigating numerous network problems caused by traffic distribution.

[0106] In some embodiments, the session state is serialized in the above steps and transmitted to the target end through the transmission channel between the master control side and the module side, including the following steps:

[0107] The session state is serialized into binary format, and a version number, timestamp, and checksum are appended to the serialization header to generate a serialized session state. The serialized session state is then transmitted to the target end via shared memory or a built-in control channel.

[0108] Specifically, the session state obtained in the above embodiments is serialized using a compact binary format (such as TLV or a custom format) through a state synchronization engine. Key metadata, such as a version number (for compatibility checks), a timestamp (for state freshness determination), and a checksum (for verifying data integrity, such as a MAC), is appended to the header of the generated binary data block. Subsequently, this binary data block is written to a pre-allocated shared memory area or transmitted via a dedicated SDIO command channel between the module side and the master control side.

[0109] To ensure data consistency, a double-buffering mechanism is used when writing to shared memory, or memory barriers and atomic version number updates are used to avoid the target end reading into the intermediate state of a half-written operation. Additionally, the version number can be updated during serialization of the copy buffer, and the reader can re-verify version consistency after reading. Single-write atomic updates are used for critical control bits; incremental logs are used for high-frequency changes and merged before takeover begins, shortening the freeze window.

[0110] Furthermore, integrity check codes or MACs can be added to the shared memory, and critical fields (such as TLS private keys) can only be passed as handles and used in the secure area; at the same time, only virtual socket proxy tasks are allowed to read and write the synchronization area to prevent third-party applications from tampering with it.

[0111] In this embodiment, the reliability, integrity and consistency of session state during cross-system transmission are guaranteed through serialization, verification and atomic transmission mechanisms. This avoids the state tearing problem caused by some state being updated while others are not during synchronization, thus laying the foundation for lossless migration.

[0112] In some embodiments, step S303 above, which involves restoring and taking over the network session based on the received session state, includes the following steps:

[0113] By deserializing the session state, the context of the network session can be reconstructed to recover and take over the network session.

[0114] Specifically, at the target end, the serialized session state is read via shared memory. The deserialization engine parses the data blocks, reconstructing the binary stream of the session state into an instance of a session state structure in local memory. Finally, the target end's protocol stack adaptation layer uses the information in this structure to call the local protocol stack API, reconstructing the network session context, obtaining a Socket or PCB with the same state, and immediately activating it to begin processing network traffic. Unacknowledged data in the source end's send buffer, whose metadata has been recovered, is retransmitted by the target end to prevent data loss.

[0115] Furthermore, before deserialization, it is necessary to perform corresponding integrity checks and data consistency checks in accordance with the above embodiments.

[0116] When the target is the module side, the module side resumes relevant timers (e.g., retransmission timers resume according to the remaining time), continues to process reception / transmission, generates ACKs, and maintains congestion control variables, ensuring that the network session is semantically continuous at the network layer. During this period, the connection observed in the cloud remains online, unaware of whether the master controller is present.

[0117] When the target is the master control side, the module side serializes the latest PCB and writes it back to the master control shared area. The master control side can deserialize and restore local session management, or choose to continue to let the module side maintain the network session.

[0118] This embodiment enables the rapid and accurate reconstruction of a network session entity at the target end that is completely equivalent to that at the source end, thereby ensuring the continuity of network layer semantics. Furthermore, during this period, the cloud / platform maintains only one external link. Regardless of whether the master controller is in sleep mode, the platform always sees the same IP:Port 5-tuple connection, without triggering reconnection or session reconstruction. The platform does not need to be aware of the internal master controller / module switching logic; link switching is entirely completed on the device side. It also eliminates the need to handle frequent connection disconnection and reconstruction events, reducing the pressure on the platform's connection management module. Moreover, it avoids repeatedly establishing TCP connections and TLS secure channels; reduces redundant traffic such as SYN packets, ACK packets, and certificate interactions during link establishment; and saves connection tracking entries (conntrack) on gateway / NAT devices, improving overall network efficiency and saving network resources.

[0119] In some embodiments, after the target end takes over the network session, the method further includes the following steps:

[0120] In response to the migration trigger condition, a network session migration request is initiated between the master control side and the module side; at the source end that currently holds the network session, the session state of the network session is generated, and the serialized session state is transmitted to the target end; at the target end, based on the received session state, the network session is restored and taken over.

[0121] Specifically, after the initial network session migration in the above embodiments, the link switching method in the above embodiments can be further executed at the source end that currently holds the network session in response to the migration triggering condition.

[0122] The following example, using an IoT security camera operating 24 / 7, illustrates the cyclical process of two-way session migration:

[0123] After the camera starts up, the master control side initializes the TCP protocol stack and establishes a video stream transmission network session with the cloud. At this time, the network session is held by the master control side, and video streaming is executed normally. From 12:00 PM to 2:00 PM, if there is no human activity in the monitored area, the master control side meets the sleep conditions and initiates a migration request. The module side takes over the network session, the master control side enters sleep mode, and the module side maintains a long connection with the cloud. At 2:05 PM, human activity appears in the monitored area, triggering the master control side to wake up. After starting up, the master control side initiates a migration request. The module side generates the currently maintained TCP session state (including the sequence number and window parameters updated during the takeover period) and transmits it to the master control side via the SDIO channel. The master control side deserializes the state, reconstructs the context, takes over the network session, and resumes video streaming. If human activity ends at 2:30 PM and there is no activity in the monitored area for 5 minutes, the master control side again meets the sleep conditions and initiates a migration request. At this time, the master control side migrates the latest session state (including parameters updated during video streaming) to the module side, the master control side enters sleep mode, and the module side continues to maintain the network session.

[0124] This embodiment supports multiple, bidirectional, and flexible migrations of session control between the master control side and the module side. During each migration, the source end generates serialized data based on the latest session state to ensure that the target end takes over the most accurate session information, avoiding session anomalies caused by state lag, and realizing dynamic resource scheduling and optimized energy consumption management.

[0125] The present embodiment will now be described and illustrated through preferred embodiments.

[0126] refer to Figure 2 This embodiment provides an OpenCPU heterogeneous system, wherein key modules include:

[0127] (1) Unified Communication Proxy Virtualization Socket Layer:

[0128] It provides standard Socket semantics (socket / connect / send / recv, etc.) to the upper layers and schedules and masks the differences in protocol stacks between the master / module sides. It is responsible for encapsulating application data frames into VSocket frames and routing them to the party currently holding the session. It can achieve seamless routing during master / module switching, ensuring that the application layer is unaware of changes in the link or the holding party. In takeover scenarios, it prioritizes ensuring the continuity of peer-to-peer acknowledgment (ACK / retransmission) semantics.

[0129] (2) State synchronization engine:

[0130] It is responsible for PCB serialization / deserialization, version management, integrity verification, and atomic replacement; it supports incremental synchronization to shorten the freeze window. Specifically, it adopts a compact binary serialization format, with the header containing a version number, timestamp, and checksum (optional MAC); when writing to the shared area, it uses a double buffering or version number + memory barrier strategy to ensure atomicity.

[0131] (3) Takeover controller module:

[0132] Implement migration triggering strategies (master control proactive request, module timeout takeover, strategy triggering, etc.), takeover confirmation, error rollback, and wake-up recovery processes. Upon successful takeover, report takeover completion to the master control side / upper layer; in case of takeover failure or verification error, execute a safety rollback or trigger a reconstruction process.

[0133] This embodiment provides a link switching method, which includes the following steps:

[0134] Step S401: In response to the migration triggering condition, when the master control side enters sleep mode, the master control side initiates a migration request to migrate the network session to the module side; when the master control side is woken up, the master control side initiates a migration request to migrate the network session to the master control side.

[0135] Step S402: At the source end that currently holds the network session, determine the corresponding migration data item according to the communication protocol type; based on the migration data item, extract the corresponding fields from the PCB and buffer metadata to generate the session state.

[0136] Step S403: Serialize the session state into binary format, and append a version number, timestamp, and checksum to the serialization header to generate a serialized session state; transmit the serialized session state to the target end via shared memory or built-in control channel.

[0137] Step S404: On the target end, the context of the network session is reconstructed by deserializing the session state in order to recover and take over the network session.

[0138] The following describes the process of network session migration when performing link switching for low-power security cameras running in a heterogeneous dual-system (Linux host + RTOS module) OpenCPU environment.

[0139] Figure 4 This is a schematic diagram of the process of the module side taking over the network session in this embodiment, as shown below. Figure 4 As shown, the process begins when the Linux master controller of a low-power camera starts due to two triggering conditions: first, the need for deep sleep energy saving triggered by no human activity recognition, user operation, or timed policies; and second, the need for resource focusing before executing high-energy-consuming computing tasks. First, the master controller (master side) sends a sleep permission / takeover request to the module (module side) (step 1), clearly indicating that the current network session needs to be handed over to the module for maintenance. After the module completes its own protocol stack readiness, memory buffer reservation, and other resource preparations, it returns a confirmation of readiness (step 2) to the master controller, completing bidirectional synchronization before takeover.

[0140] The master control enters the freeze and preparation phase: The master control briefly freezes the session state through the virtualization Socket layer, that is, it suspends the structural modification of the PCB and records the state change log (step 3) to avoid the session information from being disordered during the migration process; then it captures the minimum set of states to be migrated (step 4), and only extracts the core information necessary to maintain the session in the PCB (such as the IP / port of both ends, connection status, send and receive sequence number, buffer metadata, etc.), instead of the full amount of data, which greatly reduces the migration overhead.

[0141] The master control side enters the serialization and transmission stage: The master control performs serialization processing on the above minimum state set (step 5), and adds version number, timestamp, check code and MAC information to the data header to ensure the compatibility, timeliness and anti-tampering capability of the state data; then, the data is atomically written through the secure channel between the master control and the module (using a double buffer / version number fault tolerance strategy) (step 6) to avoid data conflicts or damage during transmission.

[0142] The module enters the takeover process: After the module detects the newly transmitted status data in real time, it first checks the data integrity (step 7) and verifies the version matching degree and check code consistency; after the verification is passed, it performs deserialization and PCB replacement (step 8), restores the binary serialized data to structured session information, and atomically replaces the PCB of the module's local protocol stack to ensure that there are no intermediate anomalies during the state transition; then it restores the timer and processes the traffic (step 9), restarts the session retransmission, heartbeat and other timers, and continues to process network data interaction with the platform / cloud (such as heartbeat packet sending and platform command response).

[0143] Finally, the module sends a confirmation of takeover completion to the master controller (step 10). At this point, the session officially enters the "module maintenance state": the master controller can shut down non-core modules and enter deep sleep (or focus on high-energy-consuming computing tasks), while the module independently maintains the network connection between the camera and the cloud, so that the cloud always perceives that the camera is "online".

[0144] Figure 5 This is a schematic diagram of the process of restoring the network session on the master control side in this embodiment, as follows: Figure 5 As shown, this scenario demonstrates a seamless transition from the module maintaining the session to the main controller waking up and resuming communication. The specific process is as follows:

[0145] The device is currently in a module-maintained session state: the module is continuously interacting with the platform / cloud through a loop (sending heartbeats and receiving commands), the main controller is in a sleep state, and the microcontroller is on standby as a hardware trigger unit.

[0146] The external event-triggered wake-up process (dual-path adaptation for multiple scenarios) includes two triggering methods: physical wake-up (such as PIR human detection, button operation) and network wake-up, covering the typical wake-up requirements of security cameras. When physical wake-up occurs, the microcontroller detects a physical trigger event (such as a PIR sensor detecting human movement or a local button being pressed) and sends a wake-up signal (level / interrupt) to the main controller (step 1), triggering the main controller hardware wake-up. After the main controller is activated, it determines whether the session needs to be restored through the state awareness interface of the virtualized Socket layer (step 2). The main controller returns a wake-up confirmation to the microcontroller (step 3), completing the closed-loop verification of the hardware trigger. The main controller sends a command to the module to set the module to wake-up mode (step 4), notifying the module to stop processing new business data and prepare to synchronize the latest session state. When the network wakes up, the downlink high-priority data (such as voice call requests, PTZ control commands) from the platform / cloud arrives at the module, triggering the arrival of downlink data (step 1); the module determines that the master controller needs to be woken up through the link awareness logic (determining that the data needs to be processed by the master controller) (step 2); the module directly sends a wake-up signal (interrupt / GPIO) to the master controller (step 3), skipping the microcontroller triggering process, and realizing the ultra-fast wake-up of network-side commands.

[0147] After the wake-up trigger is completed, the master controller and the module initiate the session recovery process. The master controller sends a recovery request to the module (step 5), clearly stating that it needs to take over the current network session. The module immediately performs a freeze operation on the current state, captures the latest PCB state (step 6), suspends PCB modification of its own protocol stack, and captures the core session information updated during the takeover period (such as the latest transmit / receive sequence number, ACK confirmation number, window size, unprocessed platform instruction buffer metadata, etc.) to ensure that the state being migrated back is the latest state synchronized with the cloud. The module serializes the above state and returns the serialized state data (step 7), appending the version number, Timestamps and checksums ensure data compatibility and tamper-proof capabilities; the module writes the latest state through a secure channel between the master controller and the module (step 8); after receiving the data, the master controller performs deserialization (step 9), restoring the binary stream to a structured PCB context; based on the deserialization result, the master controller restores session management (step 10), rebuilds the TCP / IP protocol stack state, restarts the session timer, and associates application layer buffers such as video streaming; after the master controller completes session restoration, it returns a confirmation of handover completion to the module (step 11), and the module stops maintaining the current session and switches back to the standby ready state.

[0148] Finally, the device enters the session recovery master control management stage, and the master control starts the network communication recovery process: through loop, it takes over the full data interaction with the platform / cloud (sending video streams, responding to remote commands, etc.) and returns to the normal business operation state.

[0149] For the device side, lossless switching can be achieved through protocol-level session migration. Specifically: by migrating protocol stack-level session states (such as TCP control blocks and buffer states), zero-disconnection switching is achieved, ensuring session continuity; the source end can synchronize the state of unacknowledged data packets to the target end, ensuring the correct continuation of retransmission logic and preventing data loss; furthermore, it supports multiple protocols and can extend upper-layer protocols to maintain session context. For the platform side, seamless switching can be achieved through system-level transparency and resource optimization. Specifically: the platform maintains only one external link: regardless of whether the master controller is in sleep mode, the platform always sees the same IP:Port 5-tuple connection, without triggering reconnection or session reconstruction; the platform does not need to be aware of the internal master controller / module switching logic of the device, the link switching is entirely completed on the device side, and there is no need to handle frequent connection disconnection and reconstruction events, reducing the pressure on the platform's connection management module; furthermore, it avoids repeatedly establishing TCP connections and TLS secure channels; reduces redundant traffic such as SYN packets, ACK packets, and certificate exchanges during the link establishment process; saves connection tracking entries (conntrack) on gateway / NAT devices, improving overall network efficiency and saving network resources.

[0150] It should be noted that the steps shown in the above process or in the flowchart of the accompanying figures can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0151] This embodiment provides a link switching system applicable to the link switching methods described in the above embodiments.

[0152] This embodiment also provides a computer device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0153] Optionally, the computer device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0154] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated in this embodiment.

[0155] It should be understood that the specific embodiments described herein are merely illustrative of the application and not intended to limit it. All other embodiments derived by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0156] Obviously, the accompanying drawings are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar situations based on these drawings without any creative effort. Furthermore, it is understood that although the work done in this development process may be complex and lengthy, for those skilled in the art, certain design, manufacturing, or production modifications made based on the technical content disclosed in this application are merely conventional technical means and should not be considered as insufficient disclosure of this application.

[0157] The term "embodiment" in this application refers to a specific feature, structure, or characteristic described in connection with an embodiment that may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily imply the same embodiment, nor does it imply that it is mutually exclusive with or alternative to other embodiments. It will be clearly or implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0158] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of patent protection. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the appended claims.

Claims

1. A link switching method, characterized in that, The method is implemented based on a virtualized socket layer deployed on the main control side and module side of an OpenCPU heterogeneous system; the method includes: In response to the migration triggering condition, a migration request for a network session is initiated between the main control side and the module side; At the source end currently holding the network session, a session state of the network session is generated, and the serialized session state is transmitted to the target end; wherein, the source end is the master control side, and the target end is the module side; or, the source end is the module side, and the target end is the master control side; At the target end, based on the received session state, the network session is restored and taken over.

2. The link switching method according to claim 1, characterized in that, The step of initiating a network session migration request between the master control side and the module side in response to a migration trigger condition includes: When the master control side enters sleep mode, the master control side initiates a migration request to migrate the network session to the module side; When the master control side is woken up, it initiates a migration request to migrate the network session to the master control side.

3. The link switching method according to claim 1, characterized in that, The process of generating the session state of the network session and transmitting the serialized session state to the target end includes: Based on the PCB, buffer metadata, and the communication protocol type of the network session, the session state of the network session is generated; the session state includes the session state of the master control side at the time of freezing, or the session state generated by the module side during the takeover period; The session state is serialized and transmitted to the target end through the transmission channel between the main control side and the module side.

4. The link switching method according to claim 3, characterized in that, The step of generating the session state of the network session based on the PCB, buffer metadata, and the communication protocol type of the network session includes: Based on the communication protocol type, determine the corresponding migration data item; Based on the migration data items, the corresponding fields are extracted from the PCB and the buffer metadata to generate the session state.

5. The link switching method according to claim 3, characterized in that, The step of serializing the session state and transmitting it to the target end through the transmission channel between the main control side and the module side includes: The session state is serialized into binary format, and a version number, timestamp, and checksum are appended to the serialization header to generate a serialized session state. The serialized session state is transmitted to the target end via shared memory or a built-in control channel.

6. The link switching method according to claim 1, characterized in that, The step of restoring and taking over the network session based on the received session state includes: By deserializing the session state, the context of the network session is reconstructed to recover and take over the network session.

7. The link switching method according to claim 1, characterized in that, After the target end takes over the network session, the method further includes: In response to the migration triggering condition, a migration request for a network session is initiated between the main control side and the module side; At the source end currently holding the network session, the session state of the network session is generated, and the serialized session state is transmitted to the target end; At the target end, based on the received session state, the network session is restored and taken over.

8. A link switching system, characterized in that, The link switching method applicable to any one of claims 1 to 7.

9. A computer device, comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the link switching method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the link switching method according to any one of claims 1 to 7.

Images