A stream data processing method and vehicle

Abstract

This application discloses a streaming data processing method and vehicle, applied in the field of streaming data processing technology. The method includes receiving streaming response data packets from multiple concurrent data streams, each streaming response data packet carrying a data stream identifier; creating and binding a dedicated single-threaded processing unit for each data stream identifier; distributing streaming response data packets to the dedicated single-threaded processing unit bound to the corresponding data stream according to the data stream identifier; and sequentially processing all streaming response data packets distributed to that unit within the dedicated single-threaded processing unit. This method, by allocating and binding a dedicated single-threaded processing unit to each data stream identifier, ensures that streaming response data packets within each data stream can be processed sequentially when processing multiple data streams concurrently, thereby guaranteeing the orderliness and reliability of the processing.

Description

Technical Field

[0001] This application relates to the field of streaming data processing technology, specifically to a streaming data processing method and a vehicle. Background Technology

[0002] In the field of human-machine interaction for in-vehicle intelligent cockpits, the integrated application of large language models has placed higher demands on the real-time processing of streaming responses from AI assistants. Related technologies typically employ a multi-threaded concurrent processing architecture to handle concurrent data streams, with different threads processing received data packets simultaneously to improve throughput. However, this approach requires the introduction of synchronization mechanisms such as locks to coordinate the order of operations because multiple execution threads may compete for access to the same data stream or shared resources. This not only increases system complexity and overhead but can also lead to processing delays due to lock contention, and even deadlocks or data out-of-order issues, making it difficult to reliably guarantee the processing order within a single data stream in a concurrent environment.

[0003] Therefore, how to avoid out-of-order processing of concurrent streaming response data in the context of multi-task concurrent in-vehicle intelligent cockpit scenarios has become an urgent technical problem to be solved. Summary of the Invention

[0004] To address the aforementioned technical problems, this application is proposed. Embodiments of this application provide a streaming data processing method and vehicle that, by creating and binding an exclusive single-threaded processing unit to each concurrent data stream, and performing precise routing and sequential processing based on the data stream identifier, prevents out-of-order packet problems within the data stream under concurrent environments.

[0005] According to a first aspect of this application, a streaming data processing method is provided, comprising: receiving streaming response data packets from multiple concurrent data streams; wherein each streaming response data packet carries a data stream identifier; creating and binding an exclusive single-threaded processing unit for each different data stream based on the data stream identifier; and distributing the streaming response data packets to the single-threaded processing unit corresponding to the data stream identifier carried thereon, wherein different data stream identifiers correspond to different single-threaded processing units, so that streaming response data packets belonging to the same data stream identifier are submitted sequentially for processing.

[0006] As one possible implementation, after distributing the streaming response data packet to the single-threaded processing unit corresponding to the data stream identifier it carries, the streaming data processing method further includes: writing the distributed streaming response data packet into a buffer corresponding to the data stream identifier; reading the streaming response data packet from the buffer in the order of writing and processing it.

[0007] By setting up a dedicated buffer for each data stream's exclusive single-threaded processing unit, the reception and processing of data packets are decoupled. The processor can read data from the buffer according to its own capabilities, which helps to absorb the instantaneous fluctuations in the arrival of data packets, prevents data packet loss or blocking of the sender due to the single-threaded processing unit being busy, and improves the system's throughput and stability.

[0008] As one possible implementation, reading and processing the streaming response data packets from the buffer in the order of writing includes: monitoring the data backlog of the streaming response data packets in the buffer; and adjusting the processing rate or processing mode according to the data backlog.

[0009] By monitoring the data backlog in the buffer in real time and dynamically adjusting the consumption rate of reading and processing data from the buffer based on the backlog, the system can adaptively respond to load changes. This optimizes the utilization efficiency of processing resources, allowing processing at a normal rate when the backlog is low and accelerating processing when the backlog increases. This ensures timely processing while preventing the buffer from overflowing due to excessive backlog, thus maintaining the high-performance operation of the system.

[0010] As one possible implementation, adjusting the processing rate or processing mode based on the data backlog includes: increasing the processing rate when the data backlog is greater than or equal to a first threshold and less than a second threshold; and switching from processing in the order of writing to batch processing when the data backlog is greater than or equal to the second threshold.

[0011] By setting multiple backlog thresholds and implementing a tiered response strategy—for example, increasing the processing rate when the backlog reaches the first threshold and switching to batch processing mode when it reaches a higher second threshold—fine-grained control over the buffer backlog status is achieved. This strategy enables the system to take the most effective measures based on the severity of the backlog: accelerating to alleviate pressure under medium loads and significantly improving processing efficiency through batch processing under extremely high loads, thereby ensuring system stability.

[0012] As one possible implementation, the streaming data processing method includes: performing a resource release operation when the single-threaded processing unit bound to any data stream identifier completes the sequential processing of all streaming response data packets, or when the sequential processing is terminated; the resource release operation includes: releasing the exclusive single-threaded processing unit bound to the data stream identifier and clearing the corresponding buffer.

[0013] By triggering the release of the exclusive single-threaded processing unit bound to that data stream and clearing the corresponding buffer when a single data stream is completed or sequential processing is terminated, timely resource reclamation is achieved. This effectively prevents memory leaks and resource exhaustion caused by the failure to release the exclusive thread resources and memory space (buffer) of a data stream after its lifecycle ends, ensuring that the system can maintain sustainable resource utilization and overall stability even when processing a large number of concurrent data streams over a long period and in multiple rounds.

[0014] As one possible implementation, the streaming data processing method includes: sending messages to the server; wherein sending messages includes the following priority management steps: dividing messages to be sent to the server into high-priority messages and ordinary-priority messages, wherein the high-priority messages are control messages used to request the start, control, or termination of a data stream; buffering the high-priority messages and ordinary-priority messages to be sent through independent high-priority sending channels and ordinary-priority sending channels respectively; when sending messages, prioritizing the sending of high-priority messages from the high-priority sending channel.

[0015] By classifying messages into high-priority control messages and ordinary-priority data messages, and providing separate sending channels for each, messages from the high-priority channel are sent first. This ensures that critical control commands bypass potentially congested ordinary data message queues and are delivered to the server immediately. This reduces end-to-end latency of core control commands and improves the system's responsiveness to user actions or internal state changes.

[0016] As one possible implementation, the streaming data processing method includes: when a high-priority message to be sent cannot be sent immediately because the high-priority sending channel is full, storing the high-priority message in a temporary queue; when a normal-priority message to be sent cannot be sent immediately because the normal-priority sending channel is full, storing the normal-priority message in the temporary queue; resending the messages in the temporary queue through the corresponding sending channel; when the storage capacity of the temporary queue reaches its upper limit, if a new message needs to be stored, the normal-priority message stored in the temporary queue earliest is discarded first.

[0017] When the sending pressure is too high, it provides the opportunity to temporarily store and retry messages. At the same time, through the priority configuration of the discard strategy, when making trade-offs, it prioritizes the sending opportunity of newer and more critical high-priority messages, so that even under extreme congestion, it can still maintain the availability of critical system functions to the maximum extent.

[0018] As one possible implementation, the streaming data processing method includes: when a network connection with the server is detected to be disconnected, reconnecting according to an exponential backoff strategy; upon successful reconnection, sending a registration message to the server to establish a communication relationship and requesting the recovery of the streaming data response corresponding to the incomplete data stream identifier, so as to continue executing the sequential processing.

[0019] By detecting network connection drops and automatically reconnecting according to an exponential backoff strategy, and upon successful reconnection, the system automatically sends a registration message to the server requesting the resumption of incomplete data streams. This allows the system to autonomously attempt to restore communication links and data processing status when encountering network disconnections or temporary server unavailability. This enhances the system's fault tolerance to network fluctuations, avoids complete service session interruptions due to temporary network failures, achieves automatic service recovery and high availability, and ensures a continuous user experience.

[0020] As one possible implementation, after receiving streaming response data packets from multiple concurrent data streams, the streaming data processing method includes: performing integrity verification on the received streaming response data packets; discarding the streaming response data packets if the verification fails; recording a corruption log based on the discarded streaming response data packets and sending a negative acknowledgment signal to the server; and skipping the discarded streaming response data packets if no retransmission of the streaming response data packets in response to the negative acknowledgment signal is received from the server within a preset time.

[0021] By setting up integrity checks and discarding packets that fail the checks, corrupted data during transmission is actively filtered out, preventing erroneous data from contaminating subsequent processing logic and ensuring the quality of output data. Log recording and retransmission requests are implemented, along with a timeout skip mechanism for waiting for retransmissions. This prevents prolonged blocking of the entire data stream due to waiting for retransmissions of individual corrupted packets, thus achieving a balance between data accuracy and real-time processing.

[0022] According to a second aspect of this application, a vehicle is provided, comprising: a cabin; an on-board computing platform deployed within the cabin; and a streaming data processing system for performing the streaming data processing method as described in the first aspect or any implementation thereof, the streaming data processing system being integrated into the on-board computing platform.

[0023] According to a third aspect of this application, a streaming data processing apparatus is provided, comprising: a receiving module for receiving streaming response data packets from multiple concurrent data streams; wherein each streaming response data packet carries a data stream identifier; a binding module for creating and binding an exclusive single-threaded processing unit for each different data stream based on the data stream identifier; and a distribution module for distributing streaming response data packets to the single-threaded processing unit corresponding to the data stream identifier carried thereon, wherein different data stream identifiers correspond to different single-threaded processing units, so that streaming response data packets belonging to the same data stream identifier are submitted sequentially for processing.

[0024] According to a fourth aspect of this application, a computer device is provided, the computer device comprising: one or more processors; a memory; and one or more application programs, wherein the one or more application programs are stored in the memory and configured to be executed by the processor to implement the method as described in the first aspect or any implementation thereof.

[0025] According to a fifth aspect of this application, a computer-readable storage medium is provided, the storage medium storing a computer program for performing the method as described in the first aspect or any implementation thereof.

[0026] According to a sixth aspect of this application, an electronic device is provided, including a module for performing the method as described in the first aspect or any implementation thereof.

[0027] According to a seventh aspect of this application, a computer program product is provided, comprising program code for performing the method as described in the first aspect or any implementation thereof.

[0028] The streaming data processing method and vehicle provided in this application create and bind a dedicated single-threaded processing unit for each data stream identifier, and precisely route streaming response packets to the corresponding processing unit based on the data stream identifier. This allows all streaming response packets belonging to the same data stream to be processed sequentially in the same thread, preventing out-of-order issues that may occur due to concurrent execution, thus helping to ensure the sequentiality and correctness of the processing logic within each data stream. Simultaneously, by allocating independent processing units to different concurrent data streams, physical isolation and parallel processing between multiple data streams are achieved, which helps improve the overall concurrent processing capability and resource utilization of the system, achieving low-latency and efficient data processing. Furthermore, it allows multiple data streams to be processed in parallel, improving the overall concurrent processing capability and throughput of the system while ensuring the correct sequence within each data stream, effectively avoiding mutual blocking and interference between multiple data streams. Attached Figure Description

[0029] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0030] Figure 1 This is a flowchart illustrating a streaming data processing method provided in an exemplary embodiment of this application.

[0031] Figure 2 This is a schematic diagram of the structure of a streaming data processing apparatus provided in an exemplary embodiment of this application.

[0032] Figure 3 This is a structural diagram of an electronic device provided in an exemplary embodiment of this application. Detailed Implementation

[0033] Hereinafter, exemplary embodiments according to this application will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments of this application. It should be understood that this application is not limited to the exemplary embodiments described herein.

[0034] In technological fields such as in-vehicle intelligent cockpits or online interactive applications that require real-time processing of server-side streaming responses, a common technical solution for receiving and processing multiple concurrent data streams is to use multithreading or thread pool models to handle arriving data packets. These solutions respond to network input and output events through a shared pool of thread resources. The basic working principle is that the system maintains a thread pool; when the network layer detects data packets arriving from different data streams, an idle thread is allocated from the pool to perform the parsing, conversion, and subsequent forwarding tasks of that data packet. The reason for their widespread adoption is that these solutions can effectively utilize the computing power of multi-core processors, improving the overall throughput and response speed of the system through parallel processing, aiming to efficiently handle concurrent user requests.

[0035] However, these solutions fall short of expectations when applied to in-vehicle AI (Artificial Intelligence) interaction scenarios where the sequential order of response data within a single data stream must be strictly guaranteed. The fundamental contradiction lies in the fact that the multi-threaded contention processing mechanism employed to optimize overall throughput and resource utilization inevitably compromises the deterministic order of data processing within a single data stream, potentially leading to data out-of-order processing, complex thread synchronization overhead, and higher latency. For example, in an in-vehicle smart cockpit, when a user simultaneously interacts with both navigation and music AI assistants, the system creates two concurrent data streams. Since multiple data packets from the same data stream (e.g., the navigation stream) may be randomly assigned to different threads for processing, developers must introduce synchronization mechanisms such as locks and semaphores into the business logic to ensure the correct order of these data packets displayed on the final interface. This not only increases system complexity and debugging difficulty, but more importantly, the lock contention and context switching between threads introduce unpredictable latency. In resource-constrained in-vehicle embedded environments, this can result in perceived lag, severely impacting the user experience.

[0036] Analysis reveals that the root causes of the aforementioned contradictions are multifaceted: From a resource scheduling perspective, the shared thread pool model dynamically decouples data stream identifiers from processing threads, failing to physically guarantee that consecutive data packets belonging to the same data stream are processed continuously by the same execution unit. From a concurrency control perspective, the synchronization primitives introduced to maintain order cause frequent thread suspension, waiting, and waking when data packets arrive at high frequencies, resulting in significant context switching overhead that consumes valuable computation time. Furthermore, from a system architecture perspective, the traditional tightly coupled design causes mutual blocking between network reception, business processing, and interface rendering. When the processing rates of each stage are mismatched, data backlog and latency amplification can easily occur. These factors collectively limit the performance ceiling and reliability of existing solutions in addressing the low-latency, highly ordered streaming data processing requirements of automotive scenarios.

[0037] To overcome the aforementioned contradictions, this invention proposes a different technical approach. By creating and binding a dedicated single-threaded processing unit to each independent data stream identifier, and routing all data packets belonging to that data stream to the dedicated unit for sequential processing, the resource allocation and task scheduling paradigm of the data processing layer is fundamentally restructured. This eliminates resource contention within the same data stream without sacrificing the system's ability to support multiple concurrent data streams, naturally guaranteeing the processing order and preventing the performance degradation and latency caused by complex synchronization mechanisms. In other words, a streaming data processing method and vehicle are provided that can guarantee the processing order of data packets within a single data stream without introducing complex synchronization mechanisms, achieving low-latency, sequential, and efficient data processing in resource-constrained environments. Furthermore, it allows multiple data streams to be processed in parallel simultaneously, improving the overall concurrent processing capability and throughput of the system while ensuring the correct order within each data stream, effectively avoiding mutual blocking and interference between multiple data streams.

[0038] To concretize the inventive concept, a typical implementation environment is first described. The vehicle includes a cockpit, an in-vehicle computing platform deployed within the cockpit, and a streaming data processing system. The streaming data processing system is integrated into the in-vehicle computing platform and communicates with multiple remote servers. Logically, the streaming data processing system can contain several layers. A data receiving layer, such as a socket manager, is responsible for establishing and maintaining one or more communication connections with the servers via network interfaces, continuously listening for and receiving streaming response data packets pushed by the servers. A data processing layer, as the core functional layer, is connected to the data receiving layer through a communication channel and is responsible for performing business logic processing on the received data packets belonging to different data streams, such as parsing, decoding, and format conversion. A data consuming layer, such as a user interface rendering controller, is connected to the data processing layer and is responsible for converting the processed data into a user-perceptible output format, such as text rendering, speech synthesis, or graphics rendering on the in-vehicle screen. Communication between layers can be event-driven; for example, when new data arrives at the data receiving layer, an event notification is sent to the data processing layer, rather than the data processing layer continuously polling.

[0039] Figure 1 This is a flowchart illustrating a streaming data processing method provided in an exemplary embodiment of this application. This method can be executed by the streaming data processing system described above, and includes steps S110 to S130. First, streaming response data packets from multiple concurrent data streams are received (see...). Figure 1 (S110). Each streaming response packet carries a data stream identifier, and the streaming response packet is the response returned after a request is sent to the server. Next, based on the data stream identifier, a dedicated single-threaded processing unit is created and bound to each different data stream (see S110). Figure 1(S120). Then, the streaming response packet is distributed to the single-threaded processing unit corresponding to the data stream identifier it carries (see S120). Figure 1 (S130).

[0040] The following text combines Figure 1 The streaming data processing method provided in the embodiments of this application will be described in more detail.

[0041] In S110, streaming response packets from multiple concurrent data streams are received. Each streaming response packet carries a data stream identifier and is a response returned after a request is initiated to a server (e.g., an AI server). This step is performed by the system's data receiving layer, which continuously acquires streaming data segments generated by the server from the network connection. Each packet is associated with a unique data stream identifier, which helps ensure that the system can correctly distinguish and classify the packets from multiple data streams as they arrive through network interleaving.

[0042] Concurrent data streams generally refer to a sequence of continuous response data returned by the server, triggered by a single request initiated by a user to the server.

[0043] A data stream identifier is a symbol used to uniquely distinguish different data streams within a system. For example, it could be a session identifier assigned by the server at the start of a session, a thought chain identifier that runs throughout the response process, or any other unique string or numeric code.

[0044] The receiving function can be implemented in various ways, including but not limited to: establishing a persistent Transmission Control Protocol (TCP) connection or a WebSocket connection to receive pushed data; or subscribing to the data stream via server-side event sending technology based on HTTP / 2 or HTTP / 3. The way the data stream identifier is carried can also be flexible; for example, the data stream identifier can be an independent field in the application layer protocol header of the data packet, an attribute of a structured object within the payload data, or implicitly associated through a specific sub-channel carrying the data packet.

[0045] In some embodiments, data packets are processed immediately after being distributed to a single-threaded processing unit. Alternatively, a buffer can be introduced between the distribution and actual processing stages to achieve better rate decoupling and system resilience. For example, the single-threaded processing unit writes the distributed streaming response data packets into a buffer corresponding to a data stream identifier. Then, the consumption layer (e.g., the rendering control layer) reads the streaming response data packets from the buffer in the order they were written and processes them. The buffer serves as a temporary storage area for data packets before they are actually consumed. Setting up a buffer can handle bursts of data arrival and mitigate potential momentary imbalances between network reception rates and service processing rates, thereby preventing data packets from being blocked or dropped at the communication layer due to temporary busy processing units. This advantage lies in decoupling the production (reception and distribution) and consumption (service processing) stages of data packets, allowing them to operate at their own independent and potentially different optimal rates.

[0046] One way to implement a buffer is to maintain a separate memory queue as a buffer for each data stream identifier. For example, a circular buffer can be used. The system defines a `MemoryBuffer` class, which internally maintains a `RingBuffer` instance for each `chainId`. The circular buffer has a configurable capacity (e.g., 100KB) and manages data internally through write and read pointers. When a data packet is routed to a specific `chainId`, it is first serialized and written to the corresponding circular buffer, while the write pointer is updated. The single-threaded processing unit bound to that `chainId` in the `DataPump` layer is responsible for writing the data packet to its corresponding circular buffer and updating the write pointer. The consumer layer (e.g., `RenderController`) is responsible for listening to or polling the buffer. When new data is detected (the read pointer lags behind the write pointer), the data packet is read from the buffer for business processing, and the read pointer is updated. It's understandable that the buffer capacity can be adjusted within a wide range, such as from tens of KB to several MB, depending on the estimated peak data traffic, processing latency tolerance, and available memory resources. The data structure of the buffer is not limited to a circular buffer; linked list queues, array queues, and other data structures that provide sequential read and write capabilities are also applicable.

[0047] As one possible implementation, the data receiving layer maintains a WebSocket connection with the AI ​​server. When the server initiates a new streaming response, it first sends a control message containing a string named `chainId` as a unique identifier for the data stream. All subsequent data packets in this stream are sent through the same connection, with each packet's JSON payload containing this `chainId` field. After reading data from the socket, the listening coroutine in the data receiving layer first parses the `chainId`, then places the complete data packet object into a global receive buffer. Accurate extraction of the data stream identifier is fundamental to all subsequent resource isolation and routing steps, providing the system with a crucial basis for logically classifying and distributing mixed input data packets.

[0048] In S120, based on the data stream identifier, an exclusive single-threaded processing unit is created and bound to each different data stream.

[0049] A single-threaded processing unit (SLU) generally refers to any logical entity capable of sequentially executing a sequence of instructions within a single execution thread or coroutine context. During its lifetime, a SLU provides exclusive and serial computational resources to the specific data stream it is bound to, ensuring that all data processing tasks for that stream are executed linearly within this context.

[0050] This step is the core of achieving resource isolation and order guarantee. When the system first identifies a new data stream identifier, it dynamically allocates and associates a dedicated execution context for that identifier, and constrains all subsequent data processing tasks of that data stream to run within this context.

[0051] The techniques for creating and binding data streams can be flexibly chosen based on the runtime environment. As one possible implementation, in programming environments that support coroutines, a coroutine running on an independent single-threaded scheduler can be launched for each data stream identifier. For example, the `newSingleThreadContext` function from the Kotlin coroutine library can be used to create a dedicated thread context named after the data stream identifier, and a coroutine containing a processing loop can be launched within this context. This approach physically restricts all processing tasks for the data stream to execute on a single operating system thread, exclusively occupied by the coroutine scheduler, thus preventing thread-level contention with other data stream processing tasks.

[0052] As one possible implementation, a dedicated single-threaded processing unit can be implemented in various ways, not limited to the specific methods mentioned above. For example, it can include, but is not limited to: creating a separate operating system thread for a data stream identifier and running a processing loop; or creating and binding such lightweight threads in a runtime environment that supports lightweight threads and can bind them to specific kernel threads; or, in an event loop architecture, allocating a dedicated task queue for each data stream identifier and ensuring that the queue is processed sequentially by one and only one consumer thread.

[0053] The above-mentioned creation and binding functionality can be implemented by pre-allocating a resource pool during system initialization, or by dynamically invoking the system or runtime thread / coroutine creation interface upon first detection of a new stream. Simultaneously, the system needs to maintain a global mapping management structure, such as a concurrency-safe hash table, where the key is the data stream identifier and the value is a reference to the created single-threaded processing unit (such as a thread handle, coroutine job object, or dedicated queue reference). This mapping table constitutes the binding index between data stream identifiers and processing resources.

[0054] As one possible implementation, the system defines a `DataPumpManager` class, which internally maintains a `ConcurrentHashMap` named `coroutineMap` to store the mapping between data stream identifiers (`chainId`) and coroutine tasks (`Job`). When a `CHAIN_START` control message carrying a new `chainId` is received, the manager calls `newSingleThreadContext("DataPump-${chainId}")` to create a new single-threaded context and starts a coroutine within this context. This coroutine internally uses a `while` loop dedicated to waiting for and processing subsequent data packets routed to this unit. After successful creation, the key-value pair `[chainId, Job]` is stored in the `coroutineMap`, thus completing the binding.

[0055] Understandably, the creation timing, lifecycle management strategy, and specific data structure bound to a single-threaded processing unit can all be adjusted according to the application scenario. The essence of binding lies in establishing and maintaining a stable and exclusive mapping relationship between data stream identifiers and processing resources.

[0056] In S130, streaming response packets are distributed to single-threaded processing units corresponding to the data stream identifiers they carry. Different data stream identifiers correspond to different single-threaded processing units, ensuring that streaming response packets belonging to the same data stream identifier are submitted sequentially for processing. This step is a dynamic routing step connecting data reception and core processing. Its function is to precisely guide each packet to a dedicated processing unit serving that data stream based on its identity (i.e., the data stream identifier it carries), ensuring that the identifier-resource mapping relationship is executed at the data flow level.

[0057] In the context of distribution, it refers to any operation that can direct data packets to their corresponding processing resources based on data stream identifiers.

[0058] In some embodiments, the distribution action may be to deliver data packets to a private queue or communication channel that is consumed only by the target single-threaded processing unit. For example, when a single-threaded processing unit is created for each data stream in step S120, a Channel bound to that coroutine is also created. The distribution logic then finds the corresponding Channel from a global mapping table based on the data stream identifier of the data packet, and then sends the data packet to that Channel. Since each consumer has its own Channel, all data packets delivered to that Channel will be processed sequentially by its associated single consumer.

[0059] As a possible implementation, distributing data packets to the corresponding single-threaded processing unit can be achieved through various mechanisms. These include, but are not limited to: placing the data packet into a blocking queue bound to the data stream identifier, from which the corresponding processing thread cyclically retrieves it; using a callback mechanism to directly call the callback function registered by the processing unit, with the data packet as a parameter; or publishing an event with a data stream identifier and payload data on a central event bus, which is then consumed by processing units that have subscribed to the identifier. All these mechanisms can achieve precise routing based on the identifier.

[0060] In a specific example, combined with the aforementioned DataPumpManager, each single-threaded processing unit's private Channel is pre-created and stored in a separate mapping table parallel to the coroutineMap. When step S110 receives a data packet and parses out the chainId, the distribution logic running on the IO scheduler finds the corresponding Channel based on the chainId and then calls channel.send(packet) to send the data packet in either a non-blocking or blocking manner. Because the receiver of this Channel is uniquely bound to an exclusive single-threaded processing unit, the data packet is automatically routed to the correct processing context.

[0061] As a specific implementation, a single-threaded processing unit can be a loop that continuously retrieves data packets from a private Channel or queue, then calls a processing function to process them, and retrieves the next data packet after processing one packet.

[0062] In some embodiments, if a buffer is introduced, an adaptive backpressure control mechanism is provided to further address the possibility of data backlog in the buffer due to downstream consumption rates consistently falling below upstream production rates. For example, the process of reading streaming response packets from the buffer and processing them sequentially may include monitoring the amount of data backlog in the buffer's streaming response packets and adjusting the processing rate or processing mode based on the amount of data backlog.

[0063] Data backlog can be obtained in real time by calculating the difference between the write and read positions in the buffer. Dynamically adjusting the processing rate based on the data backlog is a closed-loop feedback control strategy that allows the processing rate to adaptively match the data arrival rate, preventing buffer overflows and optimizing the user experience. For example, when the backlog remains low, the processing unit can process and render at a normal rate that provides the best user experience (e.g., simulating word-by-word printing); when the backlog increases and exceeds a certain warning threshold, the processing unit can automatically accelerate the processing rate, such as reducing the interval between rendering each piece of text; when the backlog grows to a high level, indicating severe consumption lag, the processing unit can switch to batch processing mode to consume data quickly at maximum throughput.

[0064] One possible implementation is to set two gradient thresholds. When the data backlog is greater than or equal to the first threshold (e.g., 20KB) and less than the second threshold (e.g., 50KB), it is considered a moderate backlog. In this case, the processing rate of sequential processing is increased, for example, reducing the latency between rendering frames to half. When the data backlog is greater than or equal to the second threshold (e.g., 50KB), it is considered a severe backlog. In this case, processing is switched from writing order to batch processing, temporarily abandoning real-time streaming display effects, and instead reading and processing the large amount of backlogged data in the buffer at once, or performing fast rendering of the entire content to catch up with the data generation progress. Setting a gradient threshold strategy can effectively prevent the risk of memory exhaustion caused by continuous backlog in practical applications, and provide a smooth degradation experience when the system is temporarily overloaded, ensuring the availability of core functions.

[0065] Below is an example of a complete data processing flow, which begins with the data receiving operation. The data receiving layer, such as a Socket layer, is responsible for receiving streaming response data from the AI ​​server via a network interface. Data is typically pushed over a persistent network connection (such as a WebSocket connection). Each arriving data packet carries a data stream identifier (e.g., a string called a chainId) that identifies the task or session to which it belongs. The data receiving layer stores the received raw byte stream into its internal receive buffer without performing any business logic parsing or processing. This design achieves the first physical isolation in the architecture, ensuring that the data receiving layer is functionally focused and efficient.

[0066] Next, the process moves to the data processing layer. The data processing layer, such as the DataPump layer, learns of the arrival of a new data packet through an event-driven mechanism (e.g., listening for a notification channel from the data receiving layer buffer). Once awakened, the data processing layer first parses the data stream identifier (chainId) from the raw data. Then, it performs crucial routing and resource binding decisions: the system creates and binds a dedicated single-threaded processing unit for each unique data stream identifier. Specifically, if the currently parsed chainId is the first time the system has encountered it, a new single-threaded processing unit is dynamically created. This single-threaded processing unit can be implemented by creating a single-threaded coroutine. The single-threaded coroutine runs in a single-threaded context specifically created for this chainId (e.g., created using the `newSingleThreadContext("DataPump-${chainId}")` function). This means that all subsequent data packets carrying this chainId will have their processing tasks strictly confined to this single physical thread. If it is not the first time the data is encountered, the existing coroutine is reused.

[0067] After successfully routing to the corresponding dedicated single-threaded coroutine, the coroutine sequentially writes the received data packets into a dedicated memory buffer (which may be called a memoryBuffer) pre-allocated or dynamically created for that chainId. The buffer preferably uses a ring buffer structure with a fixed capacity configuration (e.g., 100KB). Because the write operations are performed serially within a single-threaded coroutine, the order in which data packets are written to the buffer naturally matches the order in which they are received by the coroutine, without the need for any locks or synchronization mechanisms for coordination.

[0068] After writing data to the buffer, the data processing layer attempts to notify the downstream data consumer layer. The data processing layer sends a data availability notification event (e.g., `notifyDataAvailable`) to the data consumer layer (e.g., the RenderController layer) via a Rendezvous Channel bound to the chainId and with zero capacity. Non-blocking methods such as `trySend` are used for this sending. If the consumer layer is busy processing the previous batch of data and cannot receive the notification immediately, the failure will be safely ignored because the data has already been persisted in the memory buffer and will not be lost. This event-based notification mechanism replaces traditional timed polling, implementing a work mode where notifications are triggered when data is available and the system sleeps when no data is available. This reduces CPU usage during idle periods and achieves millisecond-level event response latency.

[0069] The process then flows to the data consumption layer. When the data consumption layer receives a notification from the data processing layer via the event channel, the corresponding processing coroutine is awakened. The data consumption layer then initiates a read request to the memory buffer, reading data in batches from the corresponding exclusive circular buffer based on the chainId. Batch reading strategies (e.g., reading a maximum of 10KB of data or 500 characters at a time) help reduce the number of system calls and improve overall processing efficiency.

[0070] After reading the data, the data consumption layer performs processing steps, such as text decoding and business logic encapsulation, and finally calls the interface of the user interface framework to update the content of user interface elements on the screen (such as TextViews). In this step, the system can implement an adaptive backpressure control strategy: by monitoring the amount of data backlog in the memory buffer (the difference between the write position and the read position), the rendering strategy is dynamically adjusted. For example, when the backlog is small, a typewriter-style word-by-word rendering mode is used to provide the best smooth interactive experience; when the backlog exceeds a preset threshold (such as 20KB), it automatically switches to batch rendering mode to quickly consume data in the buffer to catch up with the progress and prevent memory overflow.

[0071] Ultimately, the rendered content is updated in real time to the user interface of the in-vehicle smart cockpit, thus completing the low-latency conversion from streaming data generated by the cloud-based artificial intelligence server to visual or auditory information that users can perceive in real time, thereby achieving the effect of displaying responsive text in sequence with low latency.

[0072] To aid in system resource reclamation and prevent memory leaks and resource idleness caused by the end or abnormal termination of data streams, some embodiments may also provide resource release operations. For example, a resource release operation is performed when a single-threaded processing unit bound to any data stream identifier completes sequential processing of all streaming response packets, or when sequential processing is terminated. The resource release operation includes releasing the exclusive single-threaded processing unit bound to the data stream identifier and clearing the corresponding buffer.

[0073] Sequential processing refers to processing data packets one by one according to the order in which they arrive at the processing unit, or according to the order indicated by the logical sequence number implied within the data packets, ensuring that the data packets that arrive first or have the earlier sequence number are processed first.

[0074] The specific content of sequential processing can be determined according to application requirements, and may include packet protocol parsing, payload decoding, business logic calculation, and data format conversion. The entire process does not require consideration of thread safety issues or the introduction of synchronization mechanisms to maintain order, because the single and exclusive nature of the execution environment already provides order guarantees.

[0075] Resource release is a crucial part of data stream lifecycle management. For example, when a CHAIN_END control message corresponding to a specific chainId is received, and its associated single-threaded processing unit has finished processing all data packets in its buffer, DataPumpManager will find the corresponding coroutine task object from the coroutineMap, call its cancel method, and wait for the coroutine resources to be safely reclaimed by the runtime environment. Simultaneously, the circular buffer instance corresponding to that chainId is deleted from the MemoryBuffer, releasing the memory it occupies. It's understandable that the triggering conditions for the release operation are not limited to normal completion. Similar, but potentially more timely, cleanup processes can be performed in cases of user-initiated cancellation, unrecoverable errors, or other abnormal termination. Furthermore, a timed scanning mechanism can be introduced to periodically check and clean up data stream resources that have been completed but not properly triggered for release, or have been idle for too long. For example, a background task could be set to run every 5 minutes to release all task-related resources whose completion time exceeds 1 hour.

[0076] As one possible implementation, to ensure timely resource reclamation, the system can provide a multi-layered cleanup strategy. For example, a unified resource cleanup function (e.g., `cleanup(chainId:String)`) can be provided. This function performs the following operations in sequence: 1. Cancel and stop the exclusive single-threaded processing coroutine corresponding to the `chainId`; 2. Clear the dedicated memory buffer bound to the `chainId`; 3. Close the event channel used to notify the data consumption layer; 4. Remove all references to the `chainId` from the global management mapping table (e.g., `coroutineMap`, `notifyChannels`). This function is called when the data stream ends normally, is canceled, or an unrecoverable error occurs. Alternatively, as a defensive backend measure, the system can run a low-priority background task that periodically scans all registered data stream contexts. For data streams that have been completed but whose cleanup function has not been called normally, or historical data streams that have been completed for more than a certain period (e.g., 1 hour), the task will force the cleanup function to be called to release resources, preventing long-term resource persistence due to missed logical branches or extreme exceptions.

[0077] To optimize the real-time performance and reliability of messages (such as requests, control commands, and heartbeats) sent to the server, especially to ensure that critical control commands are sent preferentially and promptly, priority management can be implemented in some embodiments. For example, firstly, messages to be sent to the server are divided into high-priority messages and ordinary-priority messages. High-priority messages are control messages used to request the initiation, control, or termination of concurrent data streams, such as agent registration, thought chain start, thought chain end, user forced stop commands, and flow control signals. Ordinary-priority messages include text data generated during streaming responses, acknowledgments, and periodic heartbeat packets. Then, high-priority and ordinary-priority messages are buffered through independent high-priority and ordinary-priority sending channels, respectively. Finally, when sending messages, high-priority messages from the high-priority sending channel are sent first. This dual-channel design ensures that high-priority control messages always have an independent sending path and are not blocked by ordinary data messages. The two channels are physically or logically isolated, preventing priority inversion issues.

[0078] As one possible implementation, the two channels can be two independent and thread-safe queues or channels. The sending coroutine runs in a main loop, using a Select statement or similar mechanism to prioritize listening to the higher-priority channel, only checking and sending messages from the normal-priority channel when the higher-priority channel is empty.

[0079] In extreme cases (such as momentary network congestion), the sending channel may quickly fill up. To address this issue, some embodiments further provide an overflow handling mechanism. When a high-priority message cannot be sent immediately due to a full high-priority sending channel, it is stored in a temporary queue. Similarly, when a normal-priority message cannot be sent immediately due to a full normal-priority sending channel, it is stored in a temporary queue. The system starts an asynchronous processing coroutine to continuously attempt to move messages from the temporary queue back into the corresponding sending channel and resend them through the corresponding sending channel. To prevent the temporary queue from growing indefinitely and exhausting memory, when the temporary queue reaches its storage capacity (e.g., 200 messages), if new messages still need to be added, an overflow eviction policy is executed: the earliest-added normal-priority message in the temporary queue is discarded first, while all high-priority messages are always retained. This buffering system helps ensure the security and stability of high-priority data, while maintaining overall system stability by sacrificing normal-priority messages.

[0080] Below is an example of a dual-channel message routing process. First, messages to be sent are generated. Messages to be sent to the server may be triggered by various events, such as a user initiating a new voice command through the interface, the system needing to send periodic heartbeats to maintain the connection, or as an acknowledgment response to data packets from the server. Then, message classification and initial routing are performed. The system first needs to determine the type of message to be sent. Based on predefined and configurable rules, messages are explicitly divided into two categories: high-priority messages and ordinary-priority messages. High-priority messages are typically control plane messages, requiring extremely high real-time performance and reliability, directly related to session state management and immediate response to critical user commands. Examples include AGENT_REGISTER, CHAIN_START, and CHAIN_STOP. Ordinary-priority messages mainly include data plane or maintenance plane messages, such as TEXT_DATA, ACK_CONFIRM, and HEARTBEAT. These classifications form the logical basis for all subsequent differentiated processing strategies.

[0081] After the classification decision is made, the process branches and routes messages based on their type. For messages determined to be high priority, the system attempts to send them to a high-priority sending channel. Specifically, this involves attempting to place the message into a dedicated high-priority sending channel (which can be named `highPriorityChannel`) in a non-blocking manner (e.g., by calling the `trySend` method). This channel is typically configured with a small but fixed capacity (e.g., 50 messages) to ensure rapid message turnaround and avoid message backlog. Similarly, for messages determined to be of normal priority, the system attempts to send them to a normal-priority sending channel. The message will be attempted to be placed into another independent normal-priority sending channel (which can be named `normalPriorityChannel`) with a relatively larger capacity (e.g., 500 messages). These two channels are logically and implementation-independent, ensuring physical isolation between message streams of different priorities.

[0082] In cases where a channel send attempt fails (i.e., the target channel is full), regardless of whether the message was initially routed to a high-priority or ordinary-priority channel, if the corresponding channel fails to send due to fullness, the message is not immediately discarded but written to a temporary queue. The system maintains a temporary queue (which can be named tempQueue, typically implemented as a thread-safe unbounded or large-capacity queue such as ConcurrentLinkedQueue) as a three-level buffer. All messages that cannot immediately enter their dedicated main channel are stored in this temporary queue. The temporary queue itself has a safe capacity limit (e.g., 200 messages) to prevent unlimited memory growth. When the temporary queue is about to reach its capacity limit, and new overflow messages need to be added, the system only selects to evict the earliest ordinary-priority message in the temporary queue, while all high-priority messages are retained, unaffected by the eviction policy. This design provides the highest level of reliability for critical control messages under extreme traffic pressure, ensuring that critical messages such as user stop commands are not lost due to instantaneous system overload.

[0083] The final exit point of the entire sending process is an independent and continuously running sending scheduling coroutine. This coroutine encapsulates the priority sending logic: within a loop, it uses select expressions or similar asynchronous primitives to simultaneously monitor both high-priority and normal-priority sending channels. The scheduling principle is strict and unconditional priority scheduling: it always prioritizes sending messages from high-priority channels. Only when a high-priority channel is empty will it attempt to send messages from normal-priority channels. Furthermore, this sending coroutine periodically, or when the main channel is idle, checks the temporary queue and attempts to re-transfer messages from the queue to their corresponding main sending channels, thereby gradually clearing the temporary buffer and achieving smooth traffic recovery.

[0084] To enhance the system's connection robustness and state recoverability in unstable network environments, some embodiments may include automated connection recovery and state synchronization mechanisms. This involves using a heartbeat mechanism (sending a heartbeat packet every 3 seconds) to determine if a connection has been lost; for example, three consecutive heartbeats without response are considered a disconnection. Alternatively, a socket exception can be used to determine if a connection has been lost, such as a socket read timeout (10 seconds) triggering disconnection processing. When a network connection to the server is detected to be lost, a reconnection strategy is employed according to an exponential backoff approach. For example, the first reconnection waits for 1 second, the second for 2 seconds, the third for 4 seconds, the fourth for 8 seconds, and so on, until the maximum number of retries (e.g., 5) is reached or a successful reconnection occurs. Upon successful reconnection, a registration message for establishing a communication relationship is sent to the server, and based on a locally maintained list of incomplete data stream identifiers, a request is made to restore the streaming data response corresponding to the incomplete data stream identifiers to continue sequential processing.

[0085] As one possible implementation, each single-threaded processing coroutine created for a data stream identifier (chainId) has its main loop protected by a structured exception handling block. The system implements different recovery strategies based on the exception type: First, when a CancellationException is caught, it indicates that the data processing task was terminated normally (e.g., the user actively stopped it or the session ended normally). In this case, the system executes a pre-defined resource cleanup process, smoothly releasing all resources occupied by the data stream. Second, when a network layer exception such as a SocketException is caught, it indicates a problem with the underlying connection. The system will trigger unified network reconnection logic to attempt to restore communication with the server. During or after reconnection, the state of the affected data stream can be restored or reset according to the strategy. When a severe resource exception such as OutOfMemoryError occurs, the system takes defensive measures. For example, it actively cleans up the memory buffers and coroutine resources occupied by other completed or long-idle data streams to quickly release system memory. Afterward, it can attempt to restart the currently affected data processing coroutine. For other unclassified general exceptions, the system records detailed exception logs (including chainId and exception stack trace) and automatically attempts to restart the current data processing coroutine to prevent the processing of a single data stream from becoming stuck and affecting other concurrent streams.

[0086] As one possible implementation, the system incorporates circuit breaker protection for coroutine restarts triggered by an anomaly, preventing system instability caused by unlimited restarts under continuous failures. For example, a maximum number of restarts (e.g., 3 times) can be set for each chainId within a unit time window (e.g., one minute). If the restart limit is reached within a short period, the system marks the data stream as degraded or in an error state, stops automatic restarts, and may report the error to higher layers, awaiting external intervention or diagnosis. During automatic restarts, the system retains received but unprocessed data in the data stream's memory buffer to ensure data continuity.

[0087] To ensure the reliability of transmitted data, after receiving streaming response packets from multiple concurrent data streams, data integrity verification and retransmission processing can be performed. For example, integrity verification is performed on the received streaming response packets (e.g., calculating and comparing CRC32 checksums, hash values, etc.). If the verification fails, the streaming response packet is discarded, indicating that the streaming response packet is corrupted. Based on the discarded streaming response packets, a corruption log is recorded, and a negative acknowledgment (NACK) signal is sent to the server, indicating the sequence number or range of packets that need to be retransmitted. If no streaming response packet retransmitted in response to the negative acknowledgment signal is received from the server within a preset time (e.g., 3 seconds), the discarded streaming response packets are skipped, and subsequent valid packets are processed, avoiding the entire data stream processing from stalling due to waiting for a single lost or corrupted packet.

[0088] Figure 2 This is a schematic diagram of the structure of a streaming data processing apparatus provided in an exemplary embodiment of this application, as shown below. Figure 2 As shown, the streaming data processing device 2 includes: a receiving module 21 for receiving streaming response data packets from multiple concurrent data streams; wherein each streaming response data packet carries a data stream identifier; a binding module 22 for creating and binding an exclusive single-threaded processing unit for each different data stream based on the data stream identifier; and a distribution module 23 for distributing the streaming response data packets to the single-threaded processing unit corresponding to the data stream identifier they carry, wherein different data stream identifiers correspond to different single-threaded processing units, so that streaming response data packets belonging to the same data stream identifier are submitted sequentially for processing.

[0089] As one possible implementation, the streaming data processing device 2 can be configured to: write the distributed streaming response data packets into a buffer corresponding to the data stream identifier; and read the streaming response data packets from the buffer in the order of writing and process them.

[0090] As one possible implementation, the sequential processing module 24 can be configured to: monitor the data backlog of streaming response packets in the buffer; and adjust the processing rate or processing mode according to the data backlog.

[0091] As one possible implementation, the sequential processing module 24 can be configured to: increase the processing rate when the data backlog is greater than or equal to the first threshold and less than the second threshold; and switch to batch processing when the data backlog is greater than or equal to the second threshold and the data is processed in the order of writing.

[0092] As one possible implementation, the streaming data processing device 2 can be configured to perform a resource release operation when the single-threaded processing unit bound to any data stream identifier completes the sequential processing of all streaming response data packets, or when the sequential processing is terminated; the resource release operation includes: releasing the exclusive single-threaded processing unit bound to the data stream identifier and clearing the corresponding buffer.

[0093] As one possible implementation, the streaming data processing device 2 can be configured to: send messages to a server; wherein sending messages includes the following priority management steps: dividing messages to be sent to the server into high-priority messages and ordinary-priority messages, wherein high-priority messages are control messages used to request the start, control or terminate of data streams; buffering high-priority messages and ordinary-priority messages to be sent through independent high-priority sending channels and ordinary-priority sending channels respectively; when sending messages, sending high-priority messages from high-priority sending channels first.

[0094] As one possible implementation, the streaming data processing device 2 can be configured to: store high-priority messages in a temporary queue when they cannot be sent immediately due to the high-priority sending channel being full; store ordinary-priority messages in a temporary queue when they cannot be sent immediately due to the ordinary-priority sending channel being full; resend the messages in the temporary queue through the corresponding sending channel; and when the storage capacity of the temporary queue reaches its limit, if new messages need to be stored, discard the ordinary-priority messages that were stored earliest in the temporary queue.

[0095] As one possible implementation, the streaming data processing device 2 can be configured to: when a network connection with the server is detected to be disconnected, reconnect according to an exponential backoff strategy; and when the reconnection is successful, send a registration message to the server to establish a communication relationship and request the recovery of the streaming data response corresponding to the incomplete data stream identifier so as to continue sequential processing.

[0096] As one possible implementation, the streaming data processing device 2 can be configured to: perform integrity verification on the received streaming response data packets, and discard the streaming response data packets if the verification fails; record a corruption log based on the discarded streaming response data packets and send a negative response signal to the server; and skip the discarded streaming response data packets if no streaming response data packets retransmitted in response to the negative response signal are received from the server within a preset time.

[0097] An electronic device includes: a processor; a memory for storing processor-executable instructions; and a processor for executing the streaming data processing method described in the embodiments provided in this application.

[0098] Below, for reference Figure 3 This application describes an electronic device according to embodiments thereof. The electronic device may be either or both of a first device and a second device, or a standalone device independent of them, which may communicate with the first device and the second device to receive acquired input signals from them.

[0099] Figure 3 A block diagram of an electronic device according to an embodiment of this application is illustrated.

[0100] like Figure 3 As shown, the electronic device 30 includes one or more processors 31 and memory 32.

[0101] The processor 31 may be a central processing unit (CPU) or other form of processing unit with data processing and / or instruction execution capabilities, and may control other components in the electronic device 30 to perform desired functions.

[0102] The memory 32 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 31 may execute the program instructions to implement the streaming data processing methods of the various embodiments of this application described above and / or other desired functions. Various contents such as input signals, signal components, and noise components may also be stored in the computer-readable storage medium.

[0103] In one example, the electronic device 30 may also include an input device 33 and an output device 34, which are interconnected via a bus system and / or other forms of connection mechanism (not shown).

[0104] When the electronic device is a standalone device, the input device 33 can be a communication network connector for receiving the collected input signals from the first device and the second device.

[0105] In addition, the input device 33 may also include, for example, a keyboard, a mouse, etc.

[0106] The output device 34 can output various information to the outside, including determined distance information, direction information, etc. The output device 34 may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0107] Of course, for the sake of simplicity, Figure 3 Only some of the components of the electronic device 30 relevant to this application are shown in this illustration; components such as buses, input / output interfaces, etc., are omitted. In addition, the electronic device 30 may include any other suitable components depending on the specific application.

[0108] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0109] A computer-readable storage medium stores a computer program for executing the streaming data processing method described in the embodiments provided in this application.

[0110] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0111] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this application to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

Claims

1. A streaming data processing method, characterized in that, include: Receive streaming response packets from multiple concurrent data streams; each streaming response packet carries a data stream identifier; Based on the data stream identifier, a dedicated single-threaded processing unit is created and bound to each different data stream; the streaming response data packet is distributed to the single-threaded processing unit corresponding to the data stream identifier it carries, with different data stream identifiers corresponding to different single-threaded processing units, so that streaming response data packets belonging to the same data stream identifier are submitted sequentially for processing.

2. The streaming data processing method according to claim 1, characterized in that, After distributing the streaming response data packet to the single-threaded processing unit corresponding to the data stream identifier it carries, the streaming data processing method further includes: The distributed streaming response data packets are written into the buffer corresponding to the data stream identifier; The streaming response packets are read from the buffer and processed in the order they are written.

3. The streaming data processing method according to claim 2, characterized in that, The step of reading and processing the streaming response data packets from the buffer in the order they were written includes: Monitor the data backlog of streaming response packets in the buffer; Adjust the processing rate or processing mode based on the amount of data backlog.

4. The streaming data processing method according to claim 3, characterized in that, The step of adjusting the processing rate or processing mode based on the data backlog includes: When the data backlog is greater than or equal to the first threshold and less than the second threshold, the processing rate is increased. When the backlog of data is greater than or equal to the second threshold, the processing will be switched to batch processing according to the writing order.

5. The streaming data processing method according to claim 2, characterized in that, The streaming data processing method includes: When the single-threaded processing unit bound to any data stream identifier completes the sequential processing of all streaming response packets, or when the sequential processing is terminated, a resource release operation is performed. The resource release operation includes: releasing the exclusive single-threaded processing unit bound to the data stream identifier and clearing the corresponding buffer.

6. The streaming data processing method according to claim 1, characterized in that, The streaming data processing method includes: Send a message to the server; Sending messages includes the following priority management steps: The messages to be sent to the server are divided into high-priority messages and normal-priority messages. The high-priority messages are control messages used to request the start, control or terminate of the data stream. The high-priority message and the normal-priority message to be sent are buffered by an independent high-priority transmission channel and a normal-priority transmission channel, respectively. When sending messages, prioritize sending high-priority messages from the high-priority sending channel.

7. The streaming data processing method according to claim 6, characterized in that, The streaming data processing method includes: When a high-priority message to be sent cannot be sent immediately because the high-priority sending channel is full, the high-priority message is stored in a temporary queue. When a normal priority message to be sent cannot be sent immediately because the normal priority sending channel is full, the normal priority message is stored in the temporary queue. The messages in the temporary queue are resent through the corresponding sending channel; When the storage capacity of the temporary queue reaches its limit, if a new message needs to be stored, the earliest ordinary priority message stored in the temporary queue will be discarded first.

8. The streaming data processing method according to claim 1, characterized in that, The streaming data processing method includes: When a network connection to the server is detected to be lost, reconnection is performed according to the exponential backoff strategy. Upon successful reconnection, a registration message for establishing a communication relationship is sent to the server, and a request is made to resume the streaming data response corresponding to the incomplete data stream identifier, so as to continue the sequential processing.

9. The streaming data processing method according to claim 1, characterized in that, After receiving streaming response packets from multiple concurrent data streams, the streaming data processing method includes: The received streaming response data packet is subjected to integrity verification. If the verification fails, the streaming response data packet is discarded. Based on the discarded streaming response packets, a corruption log is recorded and a negative response signal is sent to the server; If the streaming response data packet is not received from the server in response to the negative acknowledgment signal within a preset time, the discarded streaming response data packet is skipped.

10. A vehicle, characterized in that, include: cockpit; An in-vehicle computing platform is deployed within the cockpit; as well as A streaming data processing system for performing the streaming data processing method according to any one of claims 1-9, the streaming data processing system being integrated into the vehicle computing platform.

Images