Gateway migration system and method

Abstract

The embodiment of the invention discloses a gateway migration system and method. The system comprises an intelligent device, a storage system, a first gateway in long connection with the intelligent device and a second gateway in an available state, after the first gateway receives a restart instruction, the first gateway searches and determines a corresponding active long voice session and session state information corresponding to the session, writes the session state information into the storage system, and stores the session state information in the storage system; the method comprises the following steps: receiving an active long voice session, and sending a kicking instruction to an intelligent device corresponding to the active long voice session, the intelligent device disconnecting a long connection with a first gateway in response to the received kicking instruction, and sending a link establishment request to a second gateway, and the second gateway being used for responding to the received link establishment request. And reading corresponding session state information from the storage system according to the session identifier carried by the request to establish long connection with the intelligent equipment. The system directs the smart device to actively disconnect from the first gateway and seamlessly reconnect the second gateway based on the session state information, thereby maintaining continuity of long voice interaction during batch release.

Description

Technical Field

[0001] The present invention relates to the field of digital communication connection management, and in particular to a gateway migration system and method. Background Art

[0002] With the rapid development of intelligent voice interaction devices (such as smart speakers and smart wearables), more and more application scenarios require support for prolonged voice interaction. For example, smart speakers need to be able to process long-duration user voice commands, smart wearables need to be able to record long meeting minutes, and real-time translation applications require support for prolonged voice input. However, traditional persistent connection gateways often cause partial connection interruptions when releasing data in batches, affecting the continuity of voice interaction. Users may experience problems such as voice input interruptions and translation failures, seriously affecting the user experience.

[0003] Therefore, how to ensure the continuity of long voice interactions during the batch release of long connection gateways has become an urgent problem to be solved. Summary of the Invention

[0004] In view of this, an embodiment of the present invention provides a gateway migration system and method, which, by introducing a customized kick chain protocol, a session state persistence mechanism, a breakpoint resume mechanism, and a Redis publish / subscribe loop mechanism, enables the imperceptible migration of smart devices during the batch publishing process of the long-connection gateway, thereby ensuring the continuity of long voice sessions.

[0005] In a first aspect, a gateway migration system is provided, the system comprising: Smart devices; Storage systems; Multiple gateways, the multiple gateways including a first gateway that maintains a persistent connection with the smart device and a second gateway that is in an available state; The first gateway is configured to, in response to receiving the restart instruction, search and determine an active long voice session corresponding to the first gateway and session state information corresponding to the active long voice session, write the session state information to the storage system, and send a kick chain instruction to the smart device corresponding to the active long voice session; The smart device is configured to, in response to receiving the kick-chain instruction, disconnect the persistent connection with the first gateway and send a link establishment request to the second gateway, where the link establishment request includes a session identifier; The second gateway is configured to, in response to receiving the link establishment request, read corresponding session state information from the storage system according to the session identifier, and send a link establishment success notification to the smart device.

[0006] In a second aspect, a gateway migration method is provided, applicable to a smart device, the method comprising: Continuously obtain user voice data; Sending the user voice data to a first gateway that maintains a long connection with the smart device, so that the first gateway forwards the user voice data to a task server; In response to receiving a kick chain instruction sent by the first gateway, disconnecting the persistent connection with the first gateway; Generate a corresponding link establishment request, wherein the link establishment request includes a session identifier; Sending the link establishment request to the second gateway, so that the second gateway reads the corresponding session state information from the storage system according to the session identifier; In response to receiving the link establishment success notification, continue to send the user voice data to the second gateway.

[0007] In a third aspect, a gateway migration method is provided, applicable to a gateway, the method comprising: In response to receiving the restart instruction, searching and determining an active long voice session corresponding to the first gateway; Determining session state information corresponding to the active long voice session; Writing the session state information into a storage system; A kick chain instruction is sent to the smart device corresponding to the active long voice session, so that the smart device actively disconnects the long connection with the first gateway and establishes a long connection with the second gateway.

[0008] In a fourth aspect, a gateway migration method is provided, applicable to a gateway, the method comprising: In response to receiving a link establishment request sent by the smart device, reading corresponding session state information from a storage system according to the session identifier carried in the link establishment request, the session state information including the channel identifier; subscribing to a designated channel according to the channel identifier, where the designated channel is a channel provided in the storage system for the first gateway to publish and subscribe to user voice data; Sending a link establishment success notification to the smart device; In response to receiving the user voice data sent by the smart device, the user voice data is published to the designated channel.

[0009] In a fifth aspect, a gateway migration device is provided, the device comprising: A first acquisition module, used to continuously acquire user voice data; A first sending module is configured to send the user voice data to a first gateway that maintains a long connection with the smart device, so that the first gateway forwards the user voice data to a task server; a link breaking module, configured to disconnect the persistent connection with the first gateway in response to receiving a link-breaking instruction sent by the first gateway; A generating module, configured to generate a corresponding link establishment request, wherein the link establishment request includes a session identifier; A second sending module is configured to send the link establishment request to the second gateway, so that the second gateway reads the corresponding session state information from the storage system according to the session identifier; The third sending module is configured to continue sending the user voice data to the second gateway in response to receiving the link establishment success notification.

[0010] In a sixth aspect, a gateway migration device is provided, the device comprising: a search module, configured to search and determine, in response to receiving the restart instruction, an active long voice session corresponding to the first gateway; A first determining module, configured to determine session state information corresponding to the active long voice session; A writing module, configured to write the session state information into a storage system; The fourth sending module is used to send a kick chain instruction to the smart device corresponding to the active long voice session, so that the smart device actively disconnects the long connection with the first gateway and establishes a long connection with the second gateway.

[0011] In a seventh aspect, a gateway migration device is provided, the device comprising: a reading module configured to, in response to receiving a link establishment request sent by the smart device, read corresponding session state information from a storage system according to a session identifier carried in the link establishment request, the session state information including a channel identifier; A subscription module, configured to subscribe to a designated channel according to the channel identifier, wherein the designated channel is a channel provided in the storage system for the first gateway to publish and subscribe to user voice data; A fifth sending module, configured to send a link establishment success notification to the smart device; The publishing module is configured to publish the user voice data to the designated channel in response to receiving the user voice data sent by the smart device.

[0012] The gateway migration system of an embodiment of the present invention includes an intelligent device, a storage system, and multiple gateways, the multiple gateways including a first gateway that maintains a long connection with the intelligent device and a second gateway that is in an available state. The first gateway is used to, in response to receiving a restart instruction, search and determine the active long voice session corresponding to the first gateway and the session state information corresponding to the active long voice session, write the session state information to the storage system, and send a kick chain instruction to the intelligent device corresponding to the active long voice session. The intelligent device is used to, in response to receiving the kick chain instruction, disconnect the long connection with the first gateway and send a link establishment request to the second gateway. The link establishment request includes a session identifier. The second gateway is used to, in response to receiving the link establishment request, read the corresponding session state information from the storage system according to the session identifier and send a link establishment success notification to the intelligent device. The system guides the intelligent device to actively disconnect from the first gateway and seamlessly reconnect to the second gateway based on the session state information persisted in the storage system, thereby maintaining the continuity of the long voice interaction during batch release. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The above and other objects, features and advantages of the present invention will become more apparent through the following description of the embodiments of the present invention with reference to the accompanying drawings, in which: Figure 1 A schematic diagram of a gateway migration system according to an embodiment of the present invention; Figure 2 This is a flowchart of a long voice interaction according to an embodiment of the present invention; Figure 3 A flowchart of gateway migration interaction according to an embodiment of the present invention; Figure 4 A flowchart of a gateway migration method applicable to smart devices according to an embodiment of the present invention; Figure 5 Flowchart of a gateway migration method applicable to a gateway according to an embodiment of the present invention; Figure 6 Flowchart of a gateway migration method applicable to a gateway according to an embodiment of the present invention; Figure 7 is a schematic diagram of a gateway migration device according to an embodiment of the present invention; Figure 8 is a schematic diagram of a gateway migration device according to an embodiment of the present invention; Figure 9 Schematic diagram of a gateway migration device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0014] The present application is described below based on the following embodiments, but the present application is not limited to these embodiments. In the detailed description of the present application below, certain specific details are described in detail. Those skilled in the art can fully understand the present application without the description of these details. To avoid obscuring the essence of the present application, well-known methods, processes, procedures, components, and circuits are not described in detail.

[0015] Furthermore, persons of ordinary skill in the art will appreciate that the figures provided herein are for illustration purposes only and are not necessarily drawn to scale.

[0016] Unless the context clearly requires otherwise, words like “include”, “comprising” and the like throughout this application should be interpreted as including rather than exclusive or exhaustive; that is, as meaning “including but not limited to”.

[0017] In the description of this application, it should be understood that the terms "first", "second", etc. are used for descriptive purposes only and should not be understood to indicate or imply relative importance. In addition, in the description of this application, unless otherwise specified, "plurality" means two or more.

[0018] Any solutions described in this specification and in the examples that involve the processing of personal information will be processed only with a legitimate basis (such as with the consent of the personal information subject or as necessary for the performance of a contract) and only within the prescribed or agreed scope. A user's refusal to process personal information other than that required for basic functions will not affect their use of these functions.

[0019] Figure 1 Schematic diagram of a gateway migration system according to an embodiment of the present invention. Figure 1 As shown, the gateway migration system includes: a smart device 110, a storage system 120 and multiple gateways, wherein the multiple gateways include a first gateway 130 that maintains a long connection with the smart device 110 and a second gateway 140 that is in an available state.

[0020] The gateway migration system of this embodiment supports a custom kick-chain protocol. This protocol is a lightweight, bidirectional control protocol designed specifically for long-term connection scenarios. During batch releases, failovers, or grayscale upgrades, the server (i.e., the first gateway 130) actively guides the client (i.e., the smart device 110) to smoothly disconnect and reconnect to the new server node (i.e., the second gateway 140), ensuring zero interruption, zero packet loss, and zero repetitive processing during long voice conversations.

[0021] Furthermore, smart device 110 refers to terminal hardware that has network communication capabilities, can collect and / or play voice, and continuously interact with the gateway via a persistent connection. Smart device 110 may include, but is not limited to, smart speakers, smart headphones, translation sticks, in-car voice boxes, conference recorders, and wearable wristbands.

[0022] Furthermore, the smart device 110 includes a voice pickup component, a network communication component, a disconnection-reconnection component, and a data cache component.

[0023] The voice pickup component includes components such as a microphone array and a speaker, and is configured to continuously collect user voice data and / or broadcast results.

[0024] The network communication component is configured to establish a persistent connection with the first gateway 130, send the collected user voice data to the first gateway 130 based on the persistent connection, and receive the voice processing results returned by the first gateway 130. Specifically, it is based on the TCP / IP protocol stack and supports WebSocket, MQTT, or custom binary persistent connections.

[0025] The disconnection and reconnection component has built-in KICK / ACK_KICK frame parsing and execution logic and is configured to execute the kick chain protocol to achieve millisecond-level disconnection and reconnection. Specifically, upon receiving the kick chain command from the first gateway 130, it actively disconnects from the first gateway 130 and actively connects to the second gateway 140.

[0026] The data cache component is configured to cache unconfirmed voice frames for a short period of time and cooperate with the retry strategy to prevent packet loss.

[0027] In this embodiment, the smart device 110 is both the source of the user's voice data and the final executor of the kick chain protocol. Its reconnection behavior determines whether the system can achieve the goal of "zero interruption".

[0028] Storage system 120 can serve as a remote dictionary server (Redis). Redis is an open-source, high-performance, memory-based key-value storage system that supports a variety of data structures (such as String, Hash, List, Set, SortedSet, Stream, Pub / Sub, etc.) and provides persistence and replication mechanisms. In this embodiment, Redis plays the dual roles of a "real-time message bus" and a "session state repository." The real-time message bus refers to the publish / subscribe (Pub / Sub) communication mechanism provided by Redis, allowing publishers to send messages and subscribers to receive messages. The session state repository (key-value + TTL) refers to the storage of session state in a key-value cache. Redis Pub / Sub is used to decouple voice data producers and consumers, building a highly stable, low-latency, long-duration voice interaction data channel and effectively preventing data loss.

[0029] Both the first gateway 130 and the second gateway 140 are long-connection gateways. A long-connection gateway is a network access and session scheduling node deployed in the cloud or at the edge. It is responsible for maintaining one or more TCP / WebSocket long connections with a large number of smart devices 110 and performing functions such as data transmission and reception, protocol conversion, traffic routing, state maintenance, and fault migration throughout the entire connection lifecycle. In this embodiment, the long-connection gateway acts as a "full-duplex voice channel + session router" between the smart device 110 and the task server in the cloud, responsible for routing, authentication, load balancing, and other functions.

[0030] In one possible implementation, the system further includes a task server 150. The task server 150 refers to a general data processing device that can provide computing or application services for long voice interaction tasks. It can be a single computer, a cluster of multiple computers, or a cloud server that can flexibly adjust computing resources through cloud technology. In this embodiment, the task server 150 is configured to process the user voice data and return the voice processing results to the gateway. Specifically, its function is to convert the user voice data sent by the gateway into understandable, interactive, and storable task results through steps such as voice recognition, semantic understanding, and voice synthesis, and return them to the smart device 110 through the gateway, and then feed the results back to the user. This embodiment does not describe and limit the process of the task server 150 processing user voice data and generating results in detail. It should be understood that this process can be implemented using any existing voice processing technology.

[0031] Furthermore, the first gateway 130 is configured to, in response to receiving a restart instruction, search and determine the active long voice session corresponding to the first gateway 130 and the session state information corresponding to the active long voice session, write the session state information to the storage system 120, and send a kick chain instruction to the smart device 110 corresponding to the active long voice session.

[0032] The restart command triggers the gateway to enter the restart process. An active long voice session refers to a currently active long voice session. The session status information indicates basic information about the current session, such as the session ID, smart device ID, received voice duration, transmitted byte offset, processed event command sequence (such as WAKEUP, ASR_PARTIAL, ASR_FINAL...), last update timestamp, Redis Pub / Sub channel name (fixed as voice:stream), sampling rate, encoding format, language, task context, and other metadata.

[0033] Furthermore, the smart device 110 is configured to disconnect the persistent connection with the first gateway 130 in response to receiving the kick chain instruction, and send a link establishment request to the second gateway 140 , where the link establishment request includes a session identifier.

[0034] In addition, the link establishment request may also include information such as the smart device identification and the byte offset of the transmitted voice.

[0035] Furthermore, the second gateway 140 is configured to, in response to receiving the link establishment request, read corresponding session state information from the storage system 120 according to the session identifier, and send a link establishment success notification to the smart device 110 .

[0036] Furthermore, the session state information includes a session identifier, smart device identifier, transmitted voice byte offset, and a processed event command sequence. The session identifier identifies the corresponding session (i.e., the long voice interaction). The processed event command sequence is a chronological "event list" of all control / task events that have been fully processed and will not be repeated during this long voice interaction. Each item is a non-replayable command or result. When retransmitting, the new gateway (second gateway 140) must skip these events and continue with the next unprocessed event to avoid repeated recognition, translation, or broadcasting.

[0037] The second gateway 140 is configured to verify the link establishment request based on the device identifier. In response to the smart device identifier in the link establishment request and the smart device identifier in the session state information matching, indicating successful verification, a link establishment success notification carrying the transmitted voice byte offset is sent to the smart device 110. In response to receiving the user voice data uploaded by the smart device 110, the second gateway 140 processes the user voice data according to the processed event instruction sequence. The smart device 110 is also configured to continue uploading the user voice data from the transmitted voice byte offset after receiving the link establishment success notification. The transmitted voice byte offset is used to indicate which byte to continue receiving voice from, avoiding repeated recognition of the same audio segment. The voice stream is resumed based on the transmitted voice byte offset, avoiding data retransmission, and minimizing unnecessary data transmission during gateway migration.

[0038] Furthermore, each of the gateways (the first gateway 130 and the second gateway 140 ) is configured to send the user voice data to the task server 150 in response to receiving the user voice data uploaded by the smart device 110 that is permanently connected to the gateway.

[0039] Furthermore, the first gateway 130 is further configured to send the user voice data uploaded by the smart device 110 to a designated channel of the storage system 120 , and subscribe to the designated channel to obtain and send the user voice data to the task server.

[0040] A designated channel is a pre-agreed Pub / Sub channel name shared by all gateways, such as voice:stream. It is not a channel created for each session or device, but rather a globally unique broadcast channel. All voice frames are sent to this channel, and the session ID / device ID in the message body distinguishes different interaction sessions. This channel name is written as a constant in the gateway configuration and can be dynamically adjusted through environment variables or the configuration center, enabling unified management and horizontal scalability.

[0041] It's worth noting that the designated channels for publishing and subscribing are the same, forming a "self-publish-self-subscribe" loop within the gateway process, transferring user voice data from the receiving thread to the processing thread with zero copy, and then forwarding it to the task server. "Self-publish-self-subscribe" means that the "publisher" and "subscriber" within the same gateway share a Redis Pub / Sub channel, forming a data loop within the process or host. After voice data enters the network card, it completes a "send-receive" closed loop directly through the Redis local loopback address in milliseconds, without passing through cross-process queues or disks. This transforms "real-time voice continuously flowing through a long connection" into "an independent message stream that can be easily restarted during horizontal expansion, failover, and grayscale releases," without loss, confusion, or blockage.

[0042] Furthermore, "self-publishing and self-subscribing" can decouple the network thread from the task thread. The network thread is only responsible for receiving packets and writing to the Redis channel; the task thread is only responsible for reading the channel, initiating voice recognition, and returning packets. This way, even if the task thread is suspended due to algorithm upgrades, garbage collection, or restarts, the network thread can still "throw the user voice data into the channel" without blocking the sending window on the smart device 110.

[0043] Furthermore, "self-publishing and self-subscribing" makes Redis a migration anchor. When a gateway (here, the first gateway 130) restarts, the network thread and task thread are stopped first, but the data in the Redis channel remains. When the new gateway (here, the second gateway 140) starts up, it simply resubscribes to the same channel and can continue processing the old data, achieving "breakpoint-resume" transfer.

[0044] Furthermore, "self-publishing and self-subscribing" facilitates horizontal expansion and grayscale deployment. Specifically, the same channel can be subscribed to concurrently by multiple new gateways (broadcast mode), enabling A / B testing or traffic mirroring without requiring changes to the device SDK.

[0045] Furthermore, "self-publishing and self-subscribing" also prevents in-process queue crashes. If a local in-memory queue is used, the queue disappears upon a gateway restart. Redis channels externalize the queue, making it inherently persistent or at least allowing for a TTL to be set, ensuring data persists across restarts.

[0046] The "self-publishing-self-subscribing" Redis loop actually transforms the user voice data from a real-time voice stream into a message stream that can be migrated, cached, and replayed, allowing the gateway to restart whenever it wants without the smart device 110 being aware of it.

[0047] Furthermore, the first gateway 130 is also configured to subscribe to the designated Redis channel within the same process or the same host machine to obtain the voice data and forward it to the task server. The same process means that there are two sections of code in this process: one section is responsible for publishing the received voice packet to the designated channel; the other section is responsible for subscribing to the same designated channel, and sending the voice packet to the task thread after receiving it. These two sections of code are in the same process address space and share the same memory. The same host machine refers to the same physical machine or container. Sometimes, for high availability, two processes are started: process A only does network I / O (receive packet → publish), and process B only does task logic (subscribe → call algorithm → return packet). Although they are not in the same process, they run on the same host machine, communicate through the Redis local loopback address, and the delay is <0.1ms, which also falls within the scope of the same host machine.

[0048] Furthermore, the first gateway 130 is also configured to write the failure record back to the failure queue of the storage system 120 in response to the failure of sending or processing the user voice data, waiting for the compensation thread of the first gateway 130 or the second gateway 140 to replay or receive a receipt according to the retry strategy. Specifically, after the gateway receives the voice data through Redis subscription, if a failure occurs during forwarding or processing to the task server (network timeout, task server exception, parsing error, etc.), the gateway needs to perform fault tolerance processing: send the voice data to the task server again according to the exponential backoff strategy to achieve a retry. If the retry still fails, the failure record (including voice data, session ID, and failure reason) is written to the failure queue or Stream (such as voice:fail) of Redis to write back to Redis. Another gateway or compensation thread will periodically read the failure record from the queue for replay or receipt to ensure that the voice data is ultimately processed correctly, avoiding user session interruption or data loss.

[0049] Furthermore, the first gateway 130 is also configured to execute a complete gateway migration process of weight reset, active session detection, kick chain instruction issuance, and session status writing back to Redis before the corresponding gateway enters the restart process.

[0050] Furthermore, weight zeroing means that the first gateway 130 is further configured to call a virtual server, causing the virtual server to adjust the weight corresponding to the first gateway 130 to a predetermined value and remove traffic from the first gateway 130. The predetermined value can be 0. The virtual server (VIP Server) receives client requests and forwards them to the real server on the backend. This is used to achieve load balancing and high availability. In this embodiment, the virtual server is configured to adjust the weight of the first gateway 130 to 0 under the control of the first gateway 130 and remove traffic from the first gateway 130. Specifically, the first gateway 130 proactively calls the weight adjustment API provided by the virtual server, controls weight adjustment through the weight adjustment API, and dynamically adjusts the weight to 0 when the first gateway 130 needs to restart, achieving precise traffic removal. This weight adjustment prevents new long language interaction requests from being sent to the restarting first gateway 130, thereby avoiding the chaotic "half-old, half-new" traffic during the kick-chain migration process and ensuring zero-interruption batch release.

[0051] Furthermore, active session detection means that the first gateway 130 is specifically configured to scan all current long connections of the first gateway 130 one by one according to the device dimension to identify active long voice sessions in the connection multiplexing state, and generate an active long voice session table based on the recognition results, wherein the active long voice session table includes at least one smart device 110 that needs to execute the kick chain instruction.

[0052] Among them, scanning long connections according to the device dimension can minimize the granularity of session attribution. Specifically, only one TCP long connection is established between each smart device 110 and the gateway, but multiple event instructions may be concurrently issued within the connection, such as wake-up, ASR fragments, semantic results, etc. It can also avoid false kicks. If the scan is based on the granularity of "connection" or "session", the same device may be counted repeatedly. According to the device dimension, it can ensure that "only one entry appears for one device", thereby accurately generating the target smart device set. In addition, state consistency can be guaranteed. Specifically, when the gateway is restarted, the entire smart device 110 must be reconnected to the new node, rather than having different sessions of the smart device 110 scattered across multiple gateways, otherwise there will be broken sentences, disordered or repeated recognition.

[0053] Furthermore, the sending of the kick chain instruction means that the first gateway 130 is configured to send a kick chain instruction to the smart device 110 corresponding to the active long voice session, which will not be repeated here.

[0054] Furthermore, writing the session state back to Redis means that the first gateway 130 is configured to generate session state information corresponding to the active long voice session and write the session state information into the storage system 120. Details will not be repeated here.

[0055] Furthermore, the first gateway 130 is further configured to set a lifetime corresponding to the session state information.

[0056] Setting a TTL protects memory, maintains consistency boundaries, and simplifies cleanup logic. Specifically, long voice conversations can peak in the hundreds of thousands. TTL ensures the timely release of expired data, preventing Redis Out-of-Memory (OOM). 30 seconds is sufficient to complete the process of kicking, reconnecting, and resuming the transfer; exceeding this time is considered an exception, preventing old snapshots from interfering with new conversations. Redis automatically deletes expired keys without requiring additional background tasks to scan for expired keys, reducing system complexity.

[0057] In one possible implementation, a key name is constructed using the three-part naming scheme of migration:{gatewayId}:{deviceId}:{sessionId} to ensure global uniqueness and quick locating. The value object is then assembled and the command is written, for example, using atomic commands. If the write fails, an exponential backoff is used to retry. If it still fails after three retries, the migration:fail:{gatewayId} stream is written for processing by the compensation thread. Finally, a time-to-live (TTL) is set. The TTL can be dynamically adjusted through the configuration center, with a default value of 30 seconds. Once the TTL is written, a countdown begins; upon expiration, Redis automatically deletes the key.

[0058] Writing session state information back to Redis can achieve cross-process sharing, state migration, fault self-healing, and grayscale / rollback support. Specifically, after the first gateway 130 is restarted, the process disappears. The second gateway 140, as a new process, needs to obtain the session context. Redis can provide out-of-process shared storage. Through unified key naming, any new gateway only needs to GET migration:{gatewayId}:{deviceId}:{sessionId} to resume transmission without changing the device side. If the smart device 110 does not reconnect within the TTL, the key automatically expires and the system handles it as a session timeout to avoid the accumulation of zombie sessions. Operations and maintenance can read the session snapshot in Redis at any time to evaluate the migration progress or roll back to the old gateway.

[0059] Furthermore, the kick chain instruction also includes a byte offset of the transmitted voice and a corresponding timestamp, and the smart device 110 is further configured to continue uploading the user voice data from the byte offset after receiving the successful link establishment notification.

[0060] Furthermore, the session state information includes a channel identifier, and the second gateway 140 is configured to subscribe to the designated channel according to the channel identifier.

[0061] Furthermore, the first gateway 130 is further configured to, in response to detecting the existence of an active long voice session, detect and wait for all single event instructions of the active long voice session to be processed, and determine session state information corresponding to the active long voice session.

[0062] In one possible implementation, the first gateway 130 can determine whether a single transaction has been completed for the currently active long voice interaction based on the characteristics of the event instruction. The event instruction can be, for example, a translation or a conversation. If the event instruction is a translation, a single transaction is defined as the translation of a complete sentence. If the event instruction is a conversation, a single transaction is defined as the completion of answering a user's question or generating a complete sentence. The definition of word processing can be determined based on actual circumstances. Migrating the gateway after word processing is complete can improve the user experience and avoid noticeable pauses during voice interaction.

[0063] The gateway migration system of an embodiment of the present invention includes an intelligent device, a storage system, and multiple gateways, the multiple gateways including a first gateway that maintains a long connection with the intelligent device and a second gateway in an available state. The first gateway is used to, in response to receiving a restart instruction, search and determine the active long voice session corresponding to the first gateway and the session state information corresponding to the active long voice session, write the session state information to the storage system, and send a kick chain instruction to the intelligent device corresponding to the active long voice session. The intelligent device is used to, in response to receiving the kick chain instruction, disconnect the long connection with the first gateway and send a link establishment request to the second gateway. The link establishment request includes a session identifier. The second gateway is used to, in response to receiving the link establishment request, read the corresponding session state information from the storage system according to the session identifier and send a link establishment success notification to the intelligent device. The system guides the intelligent device to actively disconnect from the first gateway and seamlessly reconnect to the second gateway based on the persistent session state information in the storage system, thereby maintaining the continuity of long voice interaction during batch release. This embodiment uses a refined connection management and migration mechanism to actively migrate the connection to other available nodes before the gateway machine restarts, avoiding the failure of user voice interaction requests caused by direct disconnection and ensuring high availability of the service. It also ensures the real-time performance of long voice interactions during batch releases, avoiding delays and user experience interruptions caused by data retransmission. It also eliminates the need for clients to maintain complex caching and retransmission logic, reducing client development and maintenance costs. Dynamic weight adjustment by the VIP Server effectively controls traffic flow, avoids stress on restarting servers, and ensures overall system stability. The automated connection migration process reduces the need for manual intervention, reduces the workload of operations and maintenance personnel, and mitigates the risk of service interruptions caused by releases.

[0064] Figure 2 This is a long voice interaction flow chart of an embodiment of the present invention. Figure 2As shown, the long voice interaction process includes: Step S201: The smart device establishes a persistent connection with the gateway.

[0065] Specifically, the smart device and the gateway establish a TCP persistent connection through a TCP three-way handshake (SYN→SYN / ACK→ACK). The specific interaction process of establishing a persistent connection is not the focus of this embodiment and will not be detailed here.

[0066] Step S202: The smart device sends a wake-up request to the gateway.

[0067] Step S203: The gateway sends a wake-up request to the task server.

[0068] The wake-up request is used to request the task server to start a long voice interaction (or session).

[0069] Step S204: The task server sends an interaction start notification to the gateway.

[0070] Step S205: The gateway sends an interaction start notification to the smart device.

[0071] Among them, the interaction start notification is used to prompt the smart device to enter a long voice interaction.

[0072] Step S206: The smart device obtains user voice data.

[0073] Step S207: The smart device sends the user voice data to the gateway.

[0074] Step S208: The gateway sends the user voice data to the storage system, so as to publish the user voice data to a designated channel based on a publish / subscribe communication mechanism.

[0075] Step S209: The gateway starts the storage system subscription service on the same node to subscribe to the specified channel.

[0076] Step S210: The gateway subscribes to obtain user voice data from a designated channel.

[0077] Step S211: The gateway sends user voice data to the task server.

[0078] Step S212: The task server processes the user's voice data to obtain a corresponding voice processing result.

[0079] Step S213: The task server sends the voice processing result to the gateway.

[0080] Step S214: The gateway sends the voice processing result to the smart device.

[0081] In step S215 , the smart device outputs the voice processing result.

[0082] In this possible implementation, if the gateway fails to send the user voice data to the task server in step S210, or if the task server fails to process the user voice data in step S211, fault tolerance is implemented. For example, the voice data is sent to the task server again using an exponential backoff strategy. If the retry still fails, a failure record (containing the voice data, session ID, and failure reason) is written to a failure queue or stream (e.g., voice:fail) in the storage system. Another gateway or compensation thread periodically reads the failure record from the queue and replays or sends a receipt to ensure that the voice data is ultimately processed correctly, avoiding user session interruption or data loss.

[0083] The above steps S206-208 are network threads, and steps S209-215 are task threads. The two threads are decoupled and can be executed cyclically.

[0084] above Figure 2 This is a normal long voice interaction implementation process, where the gateway is the gateway that is permanently connected to the smart device, such as the first gateway before the kick chain and the second gateway after the kick chain-reconnection. The objects and operation implementation processes included in each step can be found in the above embodiment and will not be repeated here.

[0085] Figure 3 This is a flow chart of gateway migration interaction according to an embodiment of the present invention. Figure 3 The gateway migration interaction process includes: Step S301: The first gateway receives a restart notification.

[0086] At this time, the smart device maintains a long connection with the first gateway.

[0087] Step S302: The first gateway starts the gateway migration process.

[0088] Specifically, when the first gateway is about to enter the restart state, it triggers a Java shutdown hook to initiate the gateway migration process. The Java shutdown hook is a thread that executes when the Java virtual machine shuts down. By registering a shutdown hook, you can perform cleanup tasks before the JVM shuts down, such as releasing resources and saving state. In this embodiment, the shutdown hook can be used to gracefully close persistent connections, for example.

[0089] Step S303: The first gateway adjusts its own weight to 0.

[0090] Specifically, the first gateway calls the virtual server (Vip Server) API, dynamically adjusts its own weight to 0, and prohibits new connection requests from being routed to the first gateway to prevent affecting subsequent migration.

[0091] In step S304 , the first gateway performs active session detection to determine a target smart device set.

[0092] Specifically, the first gateway scans all current long connections of the corresponding long connection gateway one by one according to the device dimension to identify active long voice sessions in the connection multiplexing state, and generates an active long voice session table, which is used to determine the target smart device set that needs to execute the kick chain instruction.

[0093] In one possible implementation, the first gateway may determine whether a single processing of the currently active long voice interaction has been completed based on the characteristics of the event instruction. The event instruction may be a translation, a conversation, etc. If the event instruction is a translation, a single processing is when a complete sentence is translated. If the event instruction is a conversation, a single processing is when a question of the user is answered or a complete sentence is generated. The definition of word processing can be determined based on actual conditions. Migrating the gateway after determining that word processing is complete can improve the user experience and prevent users from noticing obvious pauses during voice interaction.

[0094] That is to say, a gateway can connect to multiple smart devices, so when a gateway is about to restart, it is necessary to first determine all the smart devices that need to be kicked off the chain.

[0095] Step S305: The first gateway determines the session state of the active long voice session.

[0096] The session status includes a session identifier, a received voice duration, and a processed event instruction sequence.

[0097] In a possible implementation, a lifetime may be set for the session state, such as 30 seconds.

[0098] Step S306: The first gateway sends the session status to Redis.

[0099] Step S307: Redis writes the session status.

[0100] Step S308: The first gateway sends a kick chain instruction to the smart device.

[0101] Specifically, if the current smart device is also one of the target smart device set, a kick chain instruction is sent to the smart device to notify the smart device that the connection is about to be disconnected and the connection is switched.

[0102] The kick chain instruction includes information such as session identifier, transmitted voice byte offset and timestamp for continued transmission.

[0103] Step S309: The smart device performs preparations before kicking the chain.

[0104] The preparation before kicking the chain may include stopping sending new user voice data.

[0105] Step S310: The smart device sends a disconnection instruction to the first gateway.

[0106] Step S311: The first gateway is disconnected from the smart device.

[0107] Step S312: The first gateway determines that all connections are disconnected.

[0108] Step S313: The first gateway enters a restart state.

[0109] Step S314: The smart device sends a link establishment request to the second gateway.

[0110] The link establishment request carries information such as a session identifier, a transmitted voice byte offset, and a timestamp.

[0111] Step S315: The second gateway reads the corresponding session state from the storage system according to the session identifier.

[0112] Specifically, after receiving the link establishment request from the smart device, the second gateway reads the session state from the storage system (such as Redis) to restore the context of the long voice interaction, and continues to subscribe to the designated channel corresponding to the long voice interaction based on the session identifier to continue to receive subsequent user voice data.

[0113] Step S316: The second gateway completes connection initialization according to the session state.

[0114] Step S317: The second gateway sends a link establishment success notification to the smart device.

[0115] Step S318: The smart device sends the user voice data to the second gateway.

[0116] Specifically, the user voice data to be transmitted is determined and sent according to the transmitted voice byte offset.

[0117] Step S319: The second gateway sends the user voice data to the task server.

[0118] After step S319 is completed, you can return to Figure 2 The corresponding node continues the long voice interaction based on the data interaction between the smart device, gateway and task server.

[0119] The specific implementation process of the above steps can be found in the above embodiments and will not be repeated here.

[0120] The interaction process of this embodiment is based on the kick chain protocol to enable the smart device to actively disconnect from the first gateway, and seamlessly reconnect to the second gateway based on the session state persisted in Redis, thereby maintaining the continuity of long voice interaction during batch release.

[0121] Figure 4 FIG. 1 is a flow chart of a gateway migration method applicable to smart devices according to an embodiment of the present invention. Figure 4 As shown, the method includes: Step S401: continuously obtain user voice data.

[0122] Step S402: Send the user voice data to a first gateway that maintains a long connection with the smart device, so that the first gateway forwards the user voice data to a task server.

[0123] Step S403: In response to receiving the kick chain instruction sent by the first gateway, disconnect the long connection with the first gateway.

[0124] Step S404: Generate a corresponding link establishment request, where the link establishment request includes a session identifier.

[0125] Step S405: Send the link establishment request to the second gateway, so that the second gateway reads the corresponding session state information from the storage system according to the session identifier.

[0126] Step S406: In response to receiving the link establishment success notification, continue sending the user voice data to the second gateway.

[0127] The specific implementation process of the above steps can be found in the above embodiments and will not be repeated here.

[0128] The method of this embodiment enables the smart device to actively disconnect from the first gateway based on the kick chain protocol, and seamlessly reconnect to the second gateway based on the session state persisted in Redis, thereby maintaining the continuity of long voice interactions during batch release.

[0129] Figure 5 FIG. 1 is a flow chart of a gateway migration method applicable to a gateway according to an embodiment of the present invention. Figure 5 As shown, the method includes: Step S501: In response to receiving a restart instruction, searching and determining an active long voice session corresponding to the first gateway.

[0130] Step S502: Determine the session state information corresponding to the active long voice session.

[0131] Step S503: Write the session state information into a storage system.

[0132] Step S504: Send a kick chain instruction to the smart device corresponding to the active long voice session, so that the smart device actively disconnects the long connection with the first gateway and establishes a long connection with the second gateway.

[0133] The specific implementation process of the above steps can be found in the above embodiments and will not be repeated here.

[0134] The method of this embodiment enables the smart device to actively disconnect from the first gateway based on the kick chain protocol, and seamlessly reconnect to the second gateway based on the session state persisted in Redis, thereby maintaining the continuity of long voice interactions during batch release.

[0135] Figure 6 FIG. 1 is a flow chart of a gateway migration method applicable to a gateway according to an embodiment of the present invention. Figure 6 As shown, the method includes: Step S601: In response to receiving a link establishment request sent by a smart device, corresponding session state information is read from a storage system according to a session identifier carried in the link establishment request, where the session state information includes a channel identifier.

[0136] Step S602: subscribing to a designated channel according to the channel identifier, where the designated channel is a channel provided in the storage system for the first gateway to publish and subscribe to user voice data.

[0137] Step S603: Send a link establishment success notification to the smart device.

[0138] Step S604: In response to receiving the user voice data sent by the smart device, publishing the user voice data to the designated channel.

[0139] The specific implementation process of the above steps can be found in the above embodiments and will not be repeated here.

[0140] The method of this embodiment enables the smart device to actively disconnect from the first gateway based on the kick chain protocol, and seamlessly reconnect to the second gateway based on the persistent session state in the storage system, thereby maintaining the continuity of long voice interactions during batch release.

[0141] Figure 7 Schematic diagram of a gateway migration device according to an embodiment of the present invention. Figure 7 As shown, the device includes: The first acquisition module 701 is used to continuously acquire user voice data.

[0142] The first sending module 702 is configured to send the user voice data to a first gateway that maintains a long connection with the smart device, so that the first gateway forwards the user voice data to a task server.

[0143] The link breaking module 703 is configured to disconnect the persistent connection with the first gateway in response to receiving a link-breaking instruction sent by the first gateway.

[0144] The generating module 704 is configured to generate a corresponding link establishment request, where the link establishment request includes a session identifier.

[0145] The second sending module 705 is configured to send the link establishment request to the second gateway, so that the second gateway reads the corresponding session state information from the storage system according to the session identifier.

[0146] The third sending module 706 is configured to continue sending the user voice data to the second gateway in response to receiving the link establishment success notification.

[0147] The apparatus of this embodiment enables the smart device to actively disconnect from the first gateway based on the kick chain protocol, and seamlessly reconnect to the second gateway based on the persistent session state in the storage system, thereby maintaining the continuity of long voice interactions during batch release.

[0148] Figure 8 Schematic diagram of a gateway migration device according to an embodiment of the present invention. Figure 8 As shown, the device includes: The search module 801 is configured to search and determine the active long voice session corresponding to the first gateway in response to receiving the restart instruction.

[0149] The first determining module 802 is configured to determine session state information corresponding to the active long voice session.

[0150] The writing module 803 is configured to write the session state information into a storage system.

[0151] The fourth sending module 804 is configured to send a kick chain instruction to the smart device corresponding to the active long voice session, so that the smart device actively disconnects the long connection with the first gateway and establishes a long connection with the second gateway.

[0152] The apparatus of this embodiment enables the smart device to actively disconnect from the first gateway based on the kick chain protocol, and seamlessly reconnect to the second gateway based on the persistent session state in the storage system, thereby maintaining the continuity of long voice interactions during batch release.

[0153] Figure 9 Schematic diagram of a gateway migration device according to an embodiment of the present invention. Figure 9 As shown, the device includes: The reading module 901 is configured to, in response to receiving a link establishment request sent by a smart device, read corresponding session state information from a storage system according to a session identifier carried in the link establishment request, where the session state information includes a channel identifier.

[0154] The subscription module 902 is configured to subscribe to a designated channel according to the channel identifier, where the designated channel is a channel provided in the storage system for the first gateway to publish and subscribe to user voice data.

[0155] The fifth sending module 903 is configured to send a link establishment success notification to the smart device.

[0156] The publishing module 904 is configured to publish the user voice data to the designated channel in response to receiving the user voice data sent by the smart device.

[0157] The apparatus of this embodiment enables the smart device to actively disconnect from the first gateway based on the kick chain protocol, and seamlessly reconnect to the second gateway based on the persistent session state in the storage system, thereby maintaining the continuity of long voice interactions during batch release.

[0158] The above-mentioned product can execute the method provided in the embodiment of this application, and has the functional modules and beneficial effects corresponding to the execution method. For technical details not fully described in this embodiment, please refer to the method provided in the embodiment of this application.

[0159] The foregoing is merely a preferred embodiment of the present application and is not intended to limit the present application. Persons skilled in the art will readily appreciate that various modifications and variations are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present application are intended to be within the scope of protection of the present application.

Claims

1. A gateway migration system, characterized in that: The system comprises: Smart devices; Storage systems; Multiple gateways, the multiple gateways including a first gateway that maintains a persistent connection with the smart device and a second gateway that is in an available state; The first gateway is configured to, in response to receiving the restart instruction, search and determine an active long voice session corresponding to the first gateway and session state information corresponding to the active long voice session, write the session state information to the storage system, and send a kick chain instruction to the smart device corresponding to the active long voice session; The smart device is configured to, in response to receiving the kick-chain instruction, disconnect the persistent connection with the first gateway and send a link establishment request to the second gateway, where the link establishment request includes a session identifier; The second gateway is configured to, in response to receiving the link establishment request, read corresponding session state information from the storage system according to the session identifier, and send a link establishment success notification to the smart device.

2. The system according to claim 1, wherein: The system also includes a task server; Each of the gateways is configured to, in response to receiving user voice data uploaded by a smart device that is permanently connected to the gateway, send the user voice data to the task server; The task server is configured to process the user voice data and return a voice processing result to the gateway.

3. The system according to claim 2, characterized in that The first gateway is further configured to send the user voice data uploaded by the smart device to a designated channel of the storage system, and subscribe to the designated channel to obtain and send the user voice data to the task server.

4. The system according to claim 3, characterized in that The first gateway is further configured to, in response to a failure in sending or processing the user voice data, write a failure record back to a failure queue of the storage system to wait for replay or receipt by the compensation thread of the first gateway or the second gateway according to a retry strategy.

5. The system according to claim 1, wherein: The first gateway is further configured to call a virtual server so that the virtual server adjusts the weight corresponding to the first gateway to a predetermined value and removes the traffic of the first gateway.

6. The system according to claim 1, wherein: The first gateway is specifically configured as follows: Scan all current long connections of the first gateway one by one according to the device dimension to identify active long voice sessions in a connection multiplexing state; An active long voice conversation table is generated according to the recognition result, where the active long voice conversation table includes at least one smart device that needs to execute a kick chain instruction.

7. The system according to claim 1, wherein: The first gateway is further configured to set a lifetime corresponding to the session state information.

8. The system according to claim 3, wherein: The kick chain instruction also includes the transmitted voice byte offset and the corresponding timestamp; The smart device is further configured to continue uploading the user voice data from the transmitted voice byte offset after receiving the link establishment success notification.

9. The system according to claim 3, wherein: The session state information includes a channel identifier; The second gateway is configured to subscribe to the designated channel according to the channel identifier.

10. The system according to claim 3, wherein: The session state information includes a session identifier, a device identifier, a transmitted voice byte offset, and a processed event instruction sequence; The second gateway is configured to verify the link establishment request according to the device identifier, and in response to successful verification, send a link establishment success notification carrying the transmitted voice byte offset to the smart device; and in response to receiving the user voice data uploaded by the smart device, process the user voice data according to the processed event instruction sequence; The smart device is further configured to continue uploading the user voice data from the byte offset after receiving the link establishment success notification.

11. The system according to claim 1, wherein: The first gateway is further configured to, in response to detecting the existence of an active long voice session, detect and wait for completion of processing of single event instructions of all active long voice sessions, and determine session state information corresponding to the active long voice session.

12. A gateway migration method, applicable to smart devices, characterized in that: The method comprises: Continuously obtain user voice data; Sending the user voice data to a first gateway that maintains a long connection with the smart device, so that the first gateway forwards the user voice data to a task server; In response to receiving a kick chain instruction sent by the first gateway, disconnecting the persistent connection with the first gateway; Generate a corresponding link establishment request, wherein the link establishment request includes a session identifier; Sending the link establishment request to the second gateway, so that the second gateway reads the corresponding session state information from the storage system according to the session identifier; In response to receiving the link establishment success notification, continue to send the user voice data to the second gateway.

13. A gateway migration method, applicable to a gateway, characterized in that: The method comprises: In response to receiving the restart instruction, searching and determining an active long voice session corresponding to the first gateway; Determining session state information corresponding to the active long voice session; Writing the session state information into a storage system; A kick chain instruction is sent to the smart device corresponding to the active long voice session, so that the smart device actively disconnects the long connection with the first gateway and establishes a long connection with the second gateway.

14. A gateway migration method, applicable to a gateway, characterized in that: The method comprises: In response to receiving a link establishment request sent by the smart device, reading corresponding session state information from a storage system according to the session identifier carried in the link establishment request, the session state information including the channel identifier; subscribing to a designated channel according to the channel identifier, where the designated channel is a channel provided in the storage system for the first gateway to publish and subscribe to user voice data; Sending a link establishment success notification to the smart device; In response to receiving the user voice data sent by the smart device, the user voice data is published to the designated channel.

Images