A method for transmitting streaming data and a vehicle

Abstract

This application discloses a method and vehicle for transmitting streaming data, applied in the field of streaming data transmission technology. The method is executed by the sending end. First, it generates corresponding data packets based on the data to be transmitted and its associated data stream; then, it transmits the data packets to the receiving end. The generated data packets have a unified structure, including a field indicating the source of the data stream, a sequence identifier field to ensure order, and a polymorphic payload field. The design of the polymorphic payload field allows it to flexibly adapt to and encapsulate multiple data types, including at least text and images. By adopting this unified message packet structure, it is unnecessary to design separate processing protocols for various data types, thus improving transmission convenience and efficiency.

Description

Technical Field

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

[0002] In the field of in-vehicle smart cockpits, with the deep integration of artificial intelligence technology, multiple AI agents need to output dynamic data streams generated during their inference process to the cockpit interface in real time to achieve a smooth human-computer interaction experience. Related technologies typically employ universal protocols with serial numbers and acknowledgment mechanisms to ensure reliable transmission of streaming data. However, when faced with the need to transmit multiple fundamentally different data types, these solutions often necessitate designing independent protocols and processing logic for each data type at the application layer, leading to complex implementation and increased maintenance overhead.

[0003] Therefore, how to solve the problems of protocol complexity and redundant processing logic caused by streaming transmission of heterogeneous data types has become an urgent technical problem to be solved in the current field of streaming data transmission technology. Summary of the Invention

[0004] To address the aforementioned technical problems, this application is proposed. Embodiments of this application provide a method and vehicle for transmitting streaming data, which improves the efficiency of streaming data transmission by unifying the structure of data packets, maintaining the simplicity and consistency of processing logic.

[0005] According to a first aspect of this application, a method for transmitting streaming data is provided at a sending end, the method comprising: generating a data packet based on data to be transmitted and a data stream context to which the data belongs; and sending data to a receiving end based on the data packet; wherein the data packet includes: a field identifying the data stream context, a sequence identifier field, and a polymorphic payload field, the polymorphic payload field being configured to select from a plurality of predetermined data types and carry data of the corresponding type, the predetermined data types including at least text and images.

[0006] As one possible implementation, generating a data packet based on the data to be transmitted and the data stream context to which the data belongs includes: in response to the data to be transmitted being a newly added text fragment relative to the same data stream context, carrying a text payload in the polymorphic payload field; wherein the text payload includes incremental text and keyword offsets; in response to the data to be transmitted being an image, carrying an image payload in the polymorphic payload field; wherein the image payload includes an image identifier, binary data, or a Uniform Resource Locator (URL).

[0007] By configuring the polymorphic payload field with specific data types—either a text payload containing incremental text and offsets, or an image payload containing image identifiers and data sources—incremental transmission and efficient resource referencing are achieved for text and images, two high-frequency data types. This reduces network transmission of redundant data, saves bandwidth, and adapts to application scenarios where text is continuously updated and images may originate from different sources.

[0008] As one possible implementation, generating a data packet based on the data to be transmitted and the data stream context to which the data belongs includes: in response to the data to be transmitted being an action to be performed, carrying an action execution payload in the polymorphic payload field; wherein the action execution payload includes an action identifier, an action name, and an initial state; in response to the data to be transmitted being an action state update, carrying an action state update payload in the polymorphic payload field; wherein the action state update payload includes an action identifier and an updated state.

[0009] By configuring either an execution action payload containing a complete action description or an execution state update payload containing only the action identifier and the new state in the polymorphic payload field according to the data content, the initiation command of the action and the subsequent state change information are clearly distinguished within a unified message structure. This avoids semantic confusion between commands and state updates during transmission, helping to ensure that the receiving end can accurately parse and process the execution logic and state tracking of the action.

[0010] As one possible implementation, the method for transmitting streaming data includes: maintaining an independent sequence number counter for the data stream context to which the data packet belongs; wherein, sending data to the receiving end based on the data packet includes: when sending data to the receiving end, obtaining an incrementing sequence number from the sequence number counter corresponding to the data stream context, and filling the sequence number into the sequence identifier field.

[0011] By maintaining an independent sequence number counter for each data stream context and retrieving and filling in an incrementing sequence number when sending data packets, an independent and ordered sequence number generation mechanism is provided for each concurrent data stream. This solves the problems of complex global sequence number management, potential conflicts, or disorder in multi-stream parallel scenarios, ensuring the strictness and reliability of the transmission order within each data stream.

[0012] As one possible implementation, the method for transmitting streaming data includes: sending an end signal to the receiving end when all data packets of a data stream have been sent; performing a connection disconnection operation in response to an acknowledgment message returned by the receiving end; and performing a preset timeout processing operation if the acknowledgment message is not received within a preset timeout period.

[0013] By sending an end signal to the receiver after all data in a data stream has been sent, and deciding whether to close the connection or wait for a timeout based on the acknowledgment message returned by the receiver, a reliable handshake mechanism for ending data stream transmission is achieved. This reduces the risk of data loss due to premature connection termination by the sender, helps ensure the integrity of transmission transactions, and avoids indefinite waiting caused by lost acknowledgment messages through the timeout mechanism.

[0014] As one possible implementation, sending data to the receiving end based on the data packet includes: pausing data transmission to the receiving end in response to a pause command sent by the receiving end; and resuming data transmission to the receiving end in response to a restore command that restores the receiving end's processing capacity.

[0015] By enabling the sender to respond to pause or resume commands from the receiver, data transmission behavior is dynamically controlled, directly linking the transmission rate to the receiver's real-time processing capabilities. This solves the problem of data backlog, loss, and even system crashes caused by the sender continuing to transmit when the receiver is overloaded. It achieves adaptive flow control based on receiver feedback, improving the overall stability and resource utilization of the system.

[0016] As one possible implementation, pausing data transmission to the receiving end in response to a pause command sent by the receiving end includes: in response to the pause command sent by the receiving end and the buffer queue being full, storing the data packets overflowing the buffer queue into a temporary queue; wherein the buffer queue is a buffer queue with a fixed capacity set up by the sending end; resuming data transmission to the receiving end in response to a recovery command that restores the receiving end's processing capacity includes: in response to the recovery command that restores the receiving end's processing capacity, resuming data transmission from the buffer queue and transferring the data in the temporary queue to the buffer queue.

[0017] By setting up a fixed-capacity buffer queue at the sending end, and storing new data in a temporary queue when transmission is paused and the queue is full, and then transferring it again when transmission resumes, a two-layer backpressure processing mechanism is constructed. This solves the problem of newly generated data being lost or blocking production threads due to lack of storage during flow control pauses, ensuring data continuity during transmission pauses and resumptions.

[0018] As one possible implementation, after sending data to the receiving end, the method for transmitting streaming data further includes: receiving an acknowledgment message sent by the receiving end; wherein the acknowledgment message includes a single successfully processed sequence number and / or a range of sequence numbers.

[0019] By enabling the acknowledgment message sent by the receiving end to carry a single sequence number or a consecutive range of sequence numbers, batch acknowledgment of multiple consecutively successfully received data packets is supported. This reduces the number and frequency of acknowledgment messages in high-speed streaming, lowers network signaling overhead and transmission latency, and improves transmission efficiency.

[0020] As one possible implementation, the fields for identifying the data stream context include an agent identifier and a chain identifier, wherein the agent identifier is used to distinguish different AI agents, and the chain identifier is used to distinguish different data streams under the same AI agent.

[0021] By defining the identifier field of the data stream context as a combination of agent identifier and chain identifier, it is possible to accurately locate and distinguish each independent data stream in complex application scenarios where multiple AI agents generate multiple data streams, laying a solid foundation for the correct routing, independent management and state maintenance of data streams.

[0022] According to a second aspect of this application, a vehicle is provided, comprising: a plurality of artificial intelligence agents for performing inference tasks and generating streaming data; a display unit for displaying the inference process of the artificial intelligence agents; and a data transmission device for performing, as a sending end, a method for transmitting streaming data as described in the first aspect or any implementation thereof, to transmit data between the artificial intelligence agents and the display unit.

[0023] According to a third aspect of this application, an apparatus for transmitting streaming data is provided, comprising: a generation module for generating a data packet based on data to be transmitted and a data stream context to which the data belongs; and a sending module for sending data to a receiving end based on the data packet; wherein the data packet includes: a field identifying the data stream context, a sequence identifier field, and a polymorphic payload field, the polymorphic payload field being configured to select from a plurality of predetermined data types and carry data of the corresponding type, the predetermined data types including at least text and images.

[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 method and vehicle for transmitting streaming data provided in this application transmit the streaming data by generating data packets with a uniform structure at the sending end. These data packets include a field identifying the data stream context, a sequence identifier field, and a key polymorphic payload field. The polymorphic payload field is configured to carry at least one of several predetermined data types, including text and images. By defining a uniform structure, the transmission logic remains completely consistent regardless of whether the payload contains text or images, eliminating the need to use different transmission channels or protocols for different types of data. Simultaneously, the sequence identifier field in the data packets allows the receiving end to accurately reorder the data packets based on this field, restoring the original data stream order at the sending end. This eliminates the need to switch underlying protocols or processing logic for different data types when transmitting various heterogeneous data types, maintaining the simplicity and uniformity of the protocol and processing logic while reliably ensuring the overall timing correctness of various data types in the final presentation, thus guaranteeing consistency in the processing and transmission efficiency. 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 method for transmitting streaming data provided in an exemplary embodiment of this application.

[0031] Figure 2 This is a schematic diagram of the structure of an apparatus for transmitting streaming data 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 applications requiring continuous and sequential data transmission, such as in-vehicle smart cockpits, online collaboration, or real-time gaming, a common technical solution for streaming various data types is to define structured message formats and send them via network protocols. This can be achieved by designing independent message structures or data fields for each data type. The basic principle is that the sender constructs a corresponding message body based on the data type, and the receiver identifies the data type and extracts the content according to predefined parsing rules. This approach is widely used because it effectively expresses and structures data content. However, its performance is less than ideal when applied to mixed data streams requiring sequential and real-time transmission of various heterogeneous data types (such as text, images, and commands). The fundamental contradiction lies in the fact that, in order to optimize the encoding efficiency and parsing clarity for a single data type, the inherent design inevitably compromises the uniformity of the protocol and the simplicity of the processing logic, even leading to negative consequences such as complex data transmission order management and difficulties in system expansion and maintenance. For example, in a smart in-vehicle cockpit, where multiple AI agents concurrently generate data including text reasoning fragments, perceived images, or executed commands, the application layer needs to maintain independent transmission protocols and processing pipelines for each data type, such as text and images, due to the lack of a unified transport structure. This not only increases the complexity of protocol design, but more importantly, it becomes difficult to maintain the sequential identifier of different data types within the global data stream, making it challenging to guarantee the overall temporal correctness of heterogeneous data such as text and images in the final presentation on a unified dimension.

[0035] The root causes of these contradictions are multifaceted: From the perspective of data structure definition, existing solutions tightly bind data types to message structures, resulting in inherently heterogeneous structures for messages carrying different data types, making them impossible to incorporate into a single sequence management framework. From the perspective of transmission control, the lack of a unified structure to simultaneously identify data types and sequences forces the application layer to rely on additional complex logic to associate and sort heterogeneous data packets from different protocol channels, increasing system complexity and error probability. Furthermore, from the perspective of system expansion, each new data type requires a new set of message definitions and processing logic, leading to protocol bloat and a surge in code maintenance costs. These factors collectively limit the performance ceiling and feasibility of existing solutions in addressing the new demand for multi-type mixed streaming data transmission.

[0036] To overcome the aforementioned contradictions, this invention proposes a different technical approach. The core concept lies in reconstructing the basic unit of data transmission by defining a unified message structure that includes a data stream context identifier, a sequence identifier, and a polymorphic payload field. This improves protocol uniformity, simplifies application-layer processing logic, and ensures the global orderliness of heterogeneous data within the stream without sacrificing the encoding and parsing efficiency of various data types. In other words, it provides a method and vehicle for transmitting streaming data, addressing the problems of protocol complexity, difficulty in sequence management, and poor scalability in the transmission of multi-type mixed data streams, achieving efficient, orderly, and easily scalable streaming data transmission.

[0037] In some embodiments, a vehicle is provided, comprising multiple artificial intelligence agents, a data transmission device, and a display unit. The artificial intelligence agents perform reasoning tasks such as perception, thinking, and execution, and continuously generate streaming data of different types, including text, images, and action commands. The data transmission device is responsible for encapsulating and sending this data according to a predetermined protocol, and managing interactions such as confirmation and flow control with the receiving end. The display unit is responsible for receiving, parsing, and displaying the data stream, forming a continuous visual chain of thought. Data is transmitted between the sending and receiving ends via wired or wireless communication links, forming a complete closed loop of data streaming transmission and application.

[0038] For multiple AI agents, such as those used for weather forecasting, navigation planning, and music recommendation, each operates independently and generates continuous inference process data, which constitutes multiple concurrent data streams. A data transmission device, acting as the sender, establishes a communication connection with a display unit, acting as the receiver. The data transmission device receives the streaming data generated by each AI agent, encapsulates and transmits it according to the method defined in this invention. The display unit receives, parses, and ultimately visualizes the streaming data from the data transmission device, for example, displaying text step-by-step with a typewriter effect or showing images sequentially.

[0039] In practice, the structured design of data packets can be manifested as a clearly layered protocol system. This system, through fields at different levels, collaboratively manages complex streaming data transmission scenarios. In some implementations, the protocol design can be divided into multiple layers, such as a message type layer, a stage type layer, and a data type layer. The message type layer uses a message type field to distinguish application layer messages with different functions. For example, this field can indicate whether the current message is a data packet message, a proxy connection management message, a data stream start message, a data stream end message, an acknowledgment message, or a flow control message. This provides a foundation for coordinating connections, data stream lifecycles, and transmission control between communicating parties. The stage type layer, through a stage type field, provides richer semantic context for data packets. In scenarios such as artificial intelligence reasoning, this field can be used to identify the reasoning stage to which the data belongs, such as the perception stage, thinking stage, or execution stage. This helps the receiving end to perform differentiated processing or visualization based on different stages. Specifically, for data packet messages carrying actual content, the incremental data type field works in conjunction with the aforementioned polymorphic payload field to form a data type layer. The incremental data type field explicitly indicates the specific semantics and change type of the data carried in the polymorphic payload field, such as incremental text appending, image appending, memory card appending, action appending, or status update. This layered and categorized design allows the protocol to accurately describe the source, stage, and nature of data changes while maintaining a unified structure, enhancing the protocol's expressive power and the system's post-analysis capabilities.

[0040] As a specific implementation, the aforementioned hierarchical concepts and field definitions can be transformed into precise message structures using a serialization framework (such as Protobuf). For example, message types, stage types, and incremental data types can be defined using enumeration values; the data flow context is represented by the agent_id and chain_id fields; the sequence is represented by the sequence_number field; and the polymorphic payload is defined using the oneof keyword as a field named payload, which includes specific options such as text_payload, image_payload, and memory_payload. This implementation rigorously maps the layered protocol logic while also achieving benefits such as efficient serialization.

[0041] Figure 1 This is a flowchart illustrating a method for transmitting streaming data according to an exemplary embodiment of this application. The method is executed by a sending end, which refers to a logical or physical entity that actively constructs and sends data packets, such as a data transmission device. The corresponding party communicating with it is a receiving end, such as a display unit. Figure 1As shown, this method mainly includes two core steps: generating data packets (S110) and sending data (S120). First, based on the data to be transmitted and the data stream context to which the data belongs, a data packet is generated (see...). Figure 1 (S110), and then based on the data packets, send data to the receiving end (see S110). Figure 1 (S120). The data packet includes: a field identifying the data stream context, a sequence identifier field, and a polymorphic payload field. The polymorphic payload field is configured to select from a variety of predefined data types and carry data of the corresponding type. The predefined data types include at least text and images.

[0042] The following text combines Figure 1 The present application provides a more detailed description of the method for transmitting streaming data provided in the embodiments of this application.

[0043] In S110, a data packet is generated based on the data to be transmitted and the data stream context to which the data belongs.

[0044] In some embodiments, the sender first needs to determine which specific data stream the current data packet belongs to. In a multi-agent, multi-task concurrent system, it is necessary to accurately distinguish the data source. To this end, the data packet includes a field to identify the data stream context. To ensure that the receiver can reassemble the data stream in its original order, each data packet carries a monotonically increasing sequence identifier within its data stream context. The data packet has a polymorphic payload field, which is configured to select one of a variety of predefined data types and carry data content of the corresponding type. Polymorphism is reflected in the specific form of the field and the subfields it contains, which depend entirely on the data type to be transmitted.

[0045] In some embodiments, the data flow is organized into multiple layers. Each AI agent is distinguished by a unique agent identifier. Each agent may initiate multiple independent inference tasks or sessions during its lifecycle; each task or session is referred to as a data flow context and is uniquely identified by a chain identifier. Therefore, a complete data flow context can be uniquely defined by both the agent identifier and the chain identifier. Data flows within these contexts in the form of packet sequences.

[0046] The term "sender" broadly refers to any logical entity or physical device that actively initiates data transmission, constructs and sends data packets. For example, a sender could be a client within an in-vehicle smart cockpit, a central computing unit within an in-vehicle smart cockpit, a client software module communicating with AI (Artificial Intelligence) services, or a standalone network device.

[0047] The term "receiving end" broadly refers to any logical entity or physical device that receives and processes data packets from the sending end. Examples include display controllers in in-vehicle smart cockpits, cloud-based data processing services, or servers responsible for data aggregation.

[0048] Streaming data refers to a sequence of data that is continuously generated over time and whose meaning is derived from the order of its generation. The complete content of streaming data may be generated and disclosed gradually over time, rather than being available all at once. Data packets are the basic unit of streaming data transmission; they are blocks of information that can be processed independently at the network protocol layer or application layer protocol.

[0049] In some embodiments, data packets can be defined by a structured message containing several core fields to carry various types of information required for streaming. These fields include a message type identifier to distinguish different message categories, a protocol version number, and a timestamp; a field to identify the data stream context; a sequence identifier field to ensure order; and a polymorphic payload field to carry the actual content. The data stream context field uniquely identifies which specific data stream the current data packet belongs to in a system where multiple concurrent data streams may exist, helping to ensure that data from different agents and tasks can be correctly distinguished and distributed. The sequence identifier field is a monotonically increasing identifier within the data stream context, assigning a definite sequential position to each data packet, thus providing the receiver with a basis for reordering the data stream and enabling the receiver to correct out-of-order problems that may occur during network transmission. The polymorphic payload field is configured to select and carry data of a corresponding type from a variety of predetermined data types. Polymorphism means that the specific form and content of this field depend on the data type to be transmitted. Predetermined data types include at least text and images, two data formats that are fundamentally different in format, size, and processing. This design allows both plain text fragments and images to be packed into the same data packet container for transmission, thus achieving protocol unification at the data structure level.

[0050] As one possible implementation, the field identifying the data flow context can be implemented using a single identifier or a composite identifier. For example, it can be a globally unique string or number, or a composite key composed of a surrogate identifier and a chain identifier. The sequence identifier field is typically an integer representing the order. The generation rule can be monotonically increasing, or it can be based on a timestamp or other values ​​that reflect a sequential relationship.

[0051] Fields identifying the data flow context can include agent identifiers and chain identifiers. Agent identifiers distinguish different AI agents, while chain identifiers distinguish different data flows or sessions within the same AI agent. This two-level identifier system provides good namespace isolation and logical clarity. The agent identifier, as the first level, isolates different business modules or service instances. The chain identifier, as the second level, isolates different task lifecycles or sessions within the same agent. Together, they constitute a globally unique data flow context identifier. This structure facilitates access control, resource allocation, and problem diagnosis. For example, during traffic control, it's possible to pause the entire agent (agent_id) or perform fine-grained control on a specific inference chain (agent_id + chain_id).

[0052] For the proxy identifier, it can be a string, a number, or a UUID. For the chain identifier, it can be an auto-incrementing number within the proxy, a timestamp, or a randomly generated unique string. In protocol messages, these two fields typically appear as top-level fields in the data packet. Understandably, the data flow context identifier can also be represented by only a globally unique chain identifier, with proxy information as an implicit attribute of that identifier or associated in other ways.

[0053] As one possible implementation, the implementation of polymorphic payload fields is not limited to a specific programming language feature. For example, polymorphic payload fields can be implemented using the `oneof` keyword in the Protocol Buffers (Protobuf) message definition language. `oneof` allows multiple optional fields to be declared in the same message definition, but during serialization, at most one of these fields can be actually set to a value; that is, a `oneof` field occupies only the space of one field and is automatically mutually exclusive. The polymorphic payload field can be any one of the following: text payload, image payload, memory payload, execution payload, or execution status update payload, and only one of these. A text payload can contain incremental text fragments and their keyword offsets; an image payload can contain an image identifier and binary data or resource addresses; a memory payload can contain a title and content text; an execution payload can contain an action identifier, name, and initial state; and an execution status update payload can contain an action identifier and the updated state. This definition allows a unified data packet message structure to flexibly carry multiple fundamentally different data types, including at least text and images, achieving minimalist unification at the protocol level. The receiver only needs to identify and parse the data type and content of the payload based on the specific item activated in the `oneof` field, without needing to maintain independent protocol parsing paths for different types. This design ensures type safety and space efficiency while also allowing for future protocol expansion; adding new data types simply requires adding new optional fields to the `oneof` definition.

[0054] As one possible implementation of S110, when the navigation AI agent begins a new path planning, the data transmission device creates a new data flow context for the inference task, assigns a unique chain identifier (chain_id), and uses it together with the agent identifier (agent_id) as the identifier of the data flow context. When the agent generates the first piece of inference text for computation, a data packet is generated based on S110. The identifier field of the data packet is filled with agent_id and chain_id, the sequence identifier field is filled with the first sequence number, and the polymorphic payload field is selected and filled with a payload structure containing the text being computed, based on the data type (text).

[0055] As mentioned earlier, polymorphic payload fields can carry various data types. In some embodiments, for text and images—two common but distinct data types—the payload content can be incrementally transmitted to improve transmission efficiency. For example, in response to the data to be transmitted being a newly added text fragment relative to the same data stream context, the text payload is carried in the polymorphic payload field. The text payload includes incremental text and keyword offsets. This setting enables incremental text transmission, avoiding the repeated transmission of historical content and thus saving network bandwidth. The principle is that, for scenarios like LLM (Large Language Model) streaming output, each newly generated data is usually a small appended segment of the entire response text. Only this incremental text is transmitted, and the receiving end simply appends it to the end of the already received text. Keyword offsets are used to identify the positions of important words in the incremental text, facilitating highlighting by the receiving end. Keyword offsets are typically based on local offsets of the current incremental text. Using this method, it is unnecessary to retransmit the entire long text with each update.

[0056] In other embodiments, in response to the data to be transmitted being an image, the image payload is carried in a polymorphic payload field. The image payload includes an image identifier, binary data, or a Uniform Resource Locator (URL). This configuration provides flexibility for image transmission. For small images (such as icons or thumbnails), directly including binary data (image_data) avoids additional network requests and reduces latency. For large images, a URL (image_url) is included, which the receiver can load on demand, avoiding blocking critical text stream transmission. The image identifier uniquely identifies the image, facilitating its reference or updating in multiple locations.

[0057] By employing the optimized payload structure for text and images described above, efficient encoding based on the characteristics of data types can be further performed within a unified message framework. This helps to solve the problems of high latency and user experience stuttering caused by transmitting large amounts of streaming data in bandwidth-constrained vehicular network environments, thereby synergistically enhancing the overall effect of efficient transmission of mixed data streams.

[0058] To support AI agents in in-vehicle smart cockpits in not only outputting information but also performing operations and providing status feedback, some embodiments can specify the data types involved in action execution. For example, in response to data to be transmitted being an action to be performed (e.g., turning on the air conditioner and turning down the volume), the execution action payload is carried in a polymorphic payload field. The execution action payload includes an action identifier, an action name, and an initial state (e.g., RUNNING), which defines the initiation of an action. In response to data to be transmitted being an action status update (e.g., execution successful or failed), the execution status update payload is carried in a polymorphic payload field. The execution status update payload includes an action identifier and the updated status (e.g., SUCCESS and FAILED). This achieves separate transmission of action instructions and status updates, a non-appendix update mode that avoids retransmitting the entire action description information when the status changes. The action identifier, as a key association field, binds the status update message to the previously sent action definition message. The receiving end can find the corresponding action item and update its status based on the action identifier without needing to know the original description of the action.

[0059] Furthermore, the state update payload can be precisely associated with previously issued execution action payloads that have the same identifier, through the included action identifier. This association enables a non-append-oriented update mechanism. The receiving end only needs to find the corresponding action entry in its internal state based on the action identifier in the state update payload and update its state field. This approach improves transmission efficiency, especially in scenarios where the state may change frequently, avoiding the repeated transmission of redundant data.

[0060] Furthermore, the names and states of actions to be executed can use predefined enumeration values ​​to further reduce transmission overhead. Understandably, the action payload can also include additional information such as a parameter list (e.g., target temperature value) and execution timeout.

[0061] The sequence identifier field can be represented as a sequence number. To ensure the correctness and isolation of sequence numbers in high-concurrency scenarios, some embodiments provide a sequence number generation management mechanism. For example, an independent sequence number counter is maintained for the data stream context to which the data packet belongs, which can increment from 1. When sending data to the receiving end, the incremented sequence number is obtained from the sequence number counter corresponding to the data stream context and filled into the sequence identifier field. Through this management mechanism, firstly, the sequence numbers between different data streams do not interfere with each other, avoiding sequence number conflicts or management chaos that may be caused by a global single counter; secondly, within each data stream, the sequence number is strictly monotonically incremented, reflecting the order in which the data is generated; and thirdly, the increment operation of the counter (such as through AtomicInteger) is atomic, which helps to ensure the uniqueness of the sequence number when concurrently sending the same data stream in a multi-threaded or multi-coroutine environment.

[0062] As one possible implementation, the sender can use a concurrent hash table (such as ConcurrentHashMap) to manage these counters. The key is the data stream context identifier (e.g., chain_id), and the value is the corresponding atomic counter. When a new data stream begins, a counter is created and registered. Each time a data packet is sent, the counter's getNextSequence() method is called to obtain the next sequence number. When the data stream ends, removeChain() is called to clean up the corresponding counter and release resources. By employing independent sequence number counters, the challenge of sequence number management during concurrent transmission of multiple data streams is solved, ensuring the reliability of the internal order of each data stream. This lays the foundation for further implementation of reliable acknowledgment and retransmission mechanisms.

[0063] Understandably, independent counters are not limited to atomic integers in software; they can also be auto-incrementing sequences in databases or snowflake algorithm ID generators in distributed environments, as long as they can generate locally ordered unique identifiers for each data stream.

[0064] In S120, data is sent to the receiving end based on data packets.

[0065] In some embodiments, the data packets generated in S110 can be retrieved from the sender's buffer or queue and sent to the receiving end on the network peer via an underlying transport protocol (such as TCP, WebSocket, or LocalSocket in an in-vehicle environment). This step ensures that the uniformly encapsulated data packets can be physically transmitted.

[0066] Specific methods for implementing the function of sending data to the receiving end may include: at the system architecture level, a dedicated sending coroutine or thread can be set up to read data packets from the sending buffer in a loop and call the network library interface to send them; at the network protocol level, data packets can be embedded as application layer payloads into standard transport layer protocol messages.

[0067] In some embodiments, the data transmission device maintains a send buffer internally. Data packets are placed into the buffer, and an independent send coroutine runs continuously. Its loop logic is as follows: check if there are data packets in the buffer; if so, retrieve one and send the serialized binary byte stream to the display unit (receiving end) in the in-vehicle smart cockpit through the established LocalSocket connection. It is understood that the implementation of the send buffer is not limited to a queue in memory; it can also be a file on disk or a record in a database. The sending triggering mechanism is not limited to coroutine polling; it can also be based on event notification or a timer.

[0068] To enable the sender to adapt to the receiver's processing capacity and prevent data backlog or loss due to receiver overload, some embodiments introduce command-based flow control. Flow control is implemented by the receiver sending specific flow control messages to the sender. For example, in response to a pause command from the receiver, the sender pauses sending data to the receiver; in response to a restore command indicating that the receiver's processing capacity has recovered, the sender resumes sending data to the receiver. A flow control message is an independent application layer protocol message, identified by its message type field as a flow control message. The message body contains at least a flow control action field and a target identifier field. Pause and restore commands are carried through the flow control message, which includes an action field whose value can be PAUSE or RESUME. The flow control action indicates PAUSE or RESUME. The target identifier field can be set to a proxy identifier for global control of all data streams under that proxy; or it can be a combination of a proxy identifier and a chain identifier for fine-grained control of a single specific data stream. Flow control messages may also optionally include information such as timestamps, protocol versions, and reasons for pauses, which facilitates logging and problem diagnosis.

[0069] As one possible implementation, the sending end has a flow control controller to maintain the current flow control state. The state typically includes two types: NORMAL (normal, no flow control) and PAUSED (paused). Its workflow is as follows: When the flow control controller receives a PAUSE message, it first checks the current state. If it is already in the PAUSED state, it ignores the repeated instruction; if the current state is NORMAL, it updates the state to PAUSED, records the relevant reason and timestamp, and then calls the pause method of the sending buffer to pause reading data packets from the buffer for network transmission. When a RESUME message is received, if the state is already NORMAL, it is ignored; if the state is PAUSED, it updates the state to NORMAL, records the information, and calls the restore method of the sending buffer to restart the transmission process. For ease of debugging, the flow control controller can record each state change event (action, reason, timestamp, and target identifier) ​​in a limited-capacity history list.

[0070] Based on this, the sending end's behavior in transmitting data to the receiving end is dynamically controllable: in response to the PAUSE command sent by the receiving end, the sending end pauses reading data from the transmission buffer and sending data; in response to the RESUME command sent by the receiving end, the sending end resumes transmission. This implements a reverse pressure transmission mechanism, allowing the receiving end to actively adjust the sending end's rate based on its own CPU, memory, or processing queue load, preventing itself from being overwhelmed.

[0071] Understandably, the triggering conditions for flow control commands can be dynamically determined by the receiving end based on indicators such as its buffer capacity and CPU utilization. This can work in conjunction with the aforementioned sequence number mechanism, ensuring that data packets can still be generated and buffered even during pauses, with sequence numbers continuously incrementing. Upon resumption, data is sent in order, helping to ensure that the order and integrity of data are not compromised by flow control.

[0072] To address the issue of storing newly generated data during the pause period at the sending end, some embodiments employ temporary queues to prevent data loss or blocking of producer threads. For example, the sending end uses a buffer queue with a fixed capacity (e.g., a channel with a limited size). When the sending end responds to a pause command from the receiving end and the buffer queue is full, newly generated data packets will not be able to be enqueued normally. The overflowing data packets are stored in a temporary queue (e.g., an unbounded or larger-capacity ConcurrentLinkedQueue). This temporary queue acts as a second-level buffer, accepting data generated during the flow control pause and when the main buffer is full. When the sending end responds to a resume command from the receiving end to restore processing capacity and needs to resume transmission, it first resumes reading and sending data packets from the buffer queue. Simultaneously, data packets temporarily stored in the temporary queue are transferred back to the buffer queue (or sent directly) to ensure that data generated during the pause is not missed.

[0073] The two-tiered architecture of fixed buffer queues and temporary queues enables controllable backpressure propagation. The fixed buffer queue limits the system's maximum memory usage, providing an upper limit on resource consumption. When backpressure is high (due to prolonged pauses at the receiving end), the temporary queue absorbs overflowing data, preventing data loss and avoiding reverse blocking of business threads due to buffer queue congestion, thus maintaining the normal operation of the producer. When resuming transmission, prioritizing data in the buffer queue helps ensure transmission continuity, while processing data in the temporary queue ensures integrity.

[0074] As one possible implementation, the buffer can contain a high-priority channel and a regular channel. The high-priority channel, with a smaller capacity, is dedicated to storing critical control messages such as connection management, data flow lifecycle (e.g., start and end), and flow control responses, ensuring the timeliness of the system control plane. The regular channel, with a larger capacity, stores regular data packet messages. When the sender pauses transmission in response to a pause command, it internally pauses data retrieval from the channel by checking flags such as `isPaused`. However, the sender can still continue generating data packets. The behavior at this time is: newly generated control messages attempt to enter the high-priority channel first, while data messages enter the regular channel. Since the channel capacity is fixed, a failed enqueue attempt means the corresponding channel is full. For data messages, they are temporarily stored in a temporary queue, thus preventing the producer thread from being blocked due to a full channel. Due to its dedicated nature, the high-priority channel typically ensures that control messages can be successfully enqueued even during pauses. When the sender resumes transmission in response to a reply command, the consumer coroutine is reactivated, prioritizing the transmission of control messages backlogged in the high-priority channel to ensure the continuity of the control flow, before processing data messages in the regular channel. Meanwhile, the system safely transfers data messages temporarily stored in the temporary queue back to the normal channel. By setting different priority channels, it ensures that no data is lost during the pause, business threads are not blocked, and critical control commands are transmitted with priority, thus achieving graceful degradation and recovery of the system under pressure.

[0075] Understandably, the specific data structures of buffer queues and temporary queues can be chosen based on the programming language and scenario, such as circular buffers and disk files. The strategy for transferring data can also be to transfer data while sending it, in order to smooth out system load.

[0076] It should be noted that the unified data packet structure defined in step S110 provides a standardized processing object for the sending operation in step S120. Regardless of whether the payload is text or an image, the sending logic remains completely consistent, eliminating the need to use different sending channels or protocols for different types of data. Simultaneously, the sequence identifier field in the data packet allows the receiving end to accurately reorder the data packets and restore the original data stream order from the sending end, even in the event of network jitter, packet retransmission, or out-of-order arrival. This synergy ensures that when transmitting various heterogeneous data types, both the simplicity and consistency of the protocol and processing logic are maintained, while reliably guaranteeing the overall temporal correctness of various data types in the final presentation, thus jointly solving the problems of protocol complexity and difficult sequence management.

[0077] To reduce network overhead and improve transmission efficiency, the format of acknowledgment messages can be optimized in some embodiments. For example, after sending a data packet, the sending end receives an acknowledgment message from the receiving end. The acknowledgment message includes a single successfully processed sequence number and / or a range of sequence numbers. That is, the data structure of the acknowledgment message can be divided into three acknowledgment modes: the first mode contains a single successfully processed sequence number; the second mode contains one or more sequence number ranges to represent a one-time acknowledgment of data packets with consecutive sequence numbers within the sequence number range; and the third mode contains both a single successfully processed sequence number and at least one sequence number range in the same acknowledgment message.

[0078] Acknowledgments based on sequence number ranges are called batch acknowledgments, and the advantages of batch acknowledgment (BACK) mode are obvious. After the receiving end has processed a large number of data packets, it is not necessary to send 100 ACKs for each data packet (e.g., sequence number 1 to 100), but only one ACK needs to be sent. The ACK range includes two fields, start and end, representing a closed interval [start, end]. This reduces the number of ACK messages, lowers network round-trip overhead and the sending pressure on the receiving end, and is especially suitable for scenarios with large data processing batches or network latency sensitivity. Single sequence number acknowledgments are suitable for critical data packets that require immediate feedback.

[0079] As one possible implementation, the acknowledgment message can define two fields: `ack_sequence` (sequence number) and `ack_ranges` (range list). The receiving end can flexibly assemble the acknowledgment message according to its own processing strategy. For example, after processing packets with sequence numbers 1-100 and 105, an ACK can be sent, where `ack_ranges=[{start:1,end:100}]` and `ack_sequence=105`. Upon receiving the ACK, the sending end needs to be able to parse this mixed format and remove the corresponding sequence number from its pending acknowledgment list. It's understood that sequence number ranges are usually required to be consecutive, but the protocol can also be designed to support multiple non-consecutive range blocks.

[0080] To ensure that all data in a data stream is fully processed by the receiving end and to prevent data loss due to premature disconnection by the sending end, some embodiments provide an elegant stream termination mechanism. This mechanism is implemented when all data packets in a data stream have been sent. A data stream is defined as a sequence of all relevant data packets generated in chronological order within a complete data interaction session with clearly defined business logic boundaries. For example, in a smart cockpit scenario, the entire multimodal interaction triggered by a user's complete voice command "Navigate to location A and play music" can be considered a data stream. A data stream begins with user input and ends with the complete presentation of the interaction result. The data packets it contains may carry text, images, or other types of data from a navigation agent, as well as text, commands, or other types of data from a music agent. Each data stream is defined by a unique data stream context identifier (such as a combination of agent identifier and chain identifier). Data packets within a data stream share the same context and maintain order through sequence identifiers. Understandably, the sender's determination of whether all data packets in a data stream have been sent is made by the upper-layer application or caller (generally referring to any software entity that needs to use this transmission service to send business data, such as a dialogue management module that performs voice command understanding, a path planning engine that generates navigation routes, or a command executor that performs vehicle control). For example, in an AI agent scenario, when a complete inference task is completed and no new data is generated, the upper-layer application will notify the sender that this data stream has ended. Upon receiving this notification and ensuring that all pending data packets belonging to this data stream have been sent to the buffer, the sender can trigger the stream termination process.

[0081] After triggering the termination process, the sender sends a termination signal to the receiver (e.g., a special ChainEndMessage). Subsequently, the sender does not immediately disconnect but waits for feedback from the receiver. Upon receiving the termination signal, the receiver marks `isInputFinished` to indicate the end of the thought chain input. The receiver waits for the `rawQueue` to be emptied, while the `DataPump` continues processing the data in the raw queue. After the `rawQueue` is emptied, the receiver sends a special ACK (acknowledgment character) to the sender. In response to the acknowledgment message returned by the receiver (a specific ACK, e.g., `sequenceNumber=0`, with no range), the sender calls `completeChain()` to perform the connection termination operation. The sender blocks and waits using `waitForEndAck()`, with a maximum timeout of 5 seconds. If no acknowledgment message is received within the preset timeout period (5 seconds), the sender performs preset timeout handling operations (such as logging errors, attempting to resend the termination signal, or forcibly disconnecting). The principle behind this END ACK mechanism is that after the sender sends a signal indicating that data transmission is complete, the receiver may still be processing the received but not yet fully processed data buffer. After processing all received data packets, the receiving end sends a final acknowledgment back to the sending end, indicating that all data has been processed and the connection can be safely closed. This helps ensure data integrity and avoids data loss caused by the sending end disconnecting while the receiving end is still processing data. The timeout mechanism provides a fault-safe boundary, preventing the sending end from waiting indefinitely due to network problems or receiving end failures.

[0082] As one possible implementation, after calling the `finish()` method, the sending end will block on a `waitForEndAck()` call with a timeout period (e.g., 5 seconds). Upon receiving the end signal, the receiving end will mark the end of the data stream input and continue processing the internal queue until it is empty, then send a special ACK with a sequence number of 0 or no sequence number. Upon receiving this ACK, the sending end will unblock, safely clean up the data stream resources, and disconnect the connection. It is understood that the specific form of the end signal and the final acknowledgment message can be a predefined message type in the protocol, and the content can include the associated data stream context identifier. Timeout handling is not limited to direct disconnection; it can also include strategies such as alarms and retries.

[0083] Figure 2 This is a schematic diagram of the structure of an apparatus for transmitting streaming data provided in an exemplary embodiment of this application, as shown below. Figure 2As shown, the apparatus 2 for transmitting streaming data includes: a generation module 21 for generating data packets based on the data to be transmitted and the data stream context to which the data belongs; and a sending module 22 for sending data to a receiving end based on the data packets; wherein the data packets include: a field identifying the data stream context, a sequence identifier field, and a polymorphic payload field, the polymorphic payload field being configured to select from a variety of predetermined data types and carry data of the corresponding type, the predetermined data types including at least text and images.

[0084] As one possible implementation, the generation module 21 can be configured to: in response to the data to be transmitted being a newly added text fragment relative to the same data stream context, carry the text payload in the polymorphic payload field; wherein the text payload includes incremental text and keyword offsets; in response to the data to be transmitted being an image, carry the image payload in the polymorphic payload field; wherein the image payload includes image identifiers, binary data, or Uniform Resource Locators.

[0085] As one possible implementation, the generation module 21 can be configured to: in response to the data to be transmitted being an action to be executed, carry the execution action payload in the polymorphic payload field; wherein, the execution action payload includes an action identifier, an action name, and an initial state; in response to the data to be transmitted being an action state update, carry the execution state update payload in the polymorphic payload field; wherein, the execution state update payload includes an action identifier and an updated state.

[0086] As one possible implementation, the device 2 for transmitting streaming data can be configured to maintain an independent sequence number counter for the data stream context to which the data packet belongs; wherein, the sending module 22 can be configured to obtain an incrementing sequence number from the sequence number counter corresponding to the data stream context when sending data to the receiving end, and fill the sequence number into the sequence identifier field.

[0087] As one possible implementation, the device 2 for transmitting streaming data can be configured to: send an end signal to the receiving end when all data packets of a data stream have been sent; perform a connection disconnection operation in response to an acknowledgment message returned by the receiving end; and perform a preset timeout processing operation if no acknowledgment message is received within a preset timeout period.

[0088] As one possible implementation, the sending module 22 can be configured to: suspend sending data to the receiving end in response to a pause command sent by the receiving end; and resume sending data to the receiving end in response to a restore command that restores the receiving end's processing capability.

[0089] As one possible implementation, the sending module 22 can be configured to: in response to a pause command sent by the receiving end and the buffer queue is full, store the data packets overflowing the buffer queue into a temporary queue; wherein the buffer queue is a buffer queue with a fixed capacity set by the sending end; in response to a restore command that restores the processing capacity of the receiving end, resume sending data from the buffer queue and transfer the data in the temporary queue to the buffer queue.

[0090] As one possible implementation, the apparatus 2 for transmitting streaming data can be configured to receive an acknowledgment message sent by a receiving end; wherein the acknowledgment message includes a single successfully processed sequence number and / or a range of sequence numbers.

[0091] As one possible implementation, the device 2 for transmitting streaming data can be configured such that the fields identifying the data stream context include an agent identifier and a chain identifier, wherein the agent identifier is used to distinguish different AI agents, and the chain identifier is used to distinguish different data streams under the same AI agent.

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

[0093] 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.

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

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

[0096] 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.

[0097] 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 methods for transmitting streaming data and / or other desired functions described in the various embodiments of this application above. Various contents such as input signals, signal components, and noise components may also be stored in the computer-readable storage medium.

[0098] 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).

[0099] 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.

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

[0101] 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.

[0102] 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.

[0103] 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.

[0104] A computer-readable storage medium stores a computer program for performing the method for transmitting streaming data as described in the embodiments provided in this application.

[0105] 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.

[0106] 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 method for transmitting streaming data, characterized in that, Applied to the sending end, the method for transmitting streaming data includes: Generate a data packet based on the data to be transmitted and the data stream context to which the data belongs; Based on the data packet, data is sent to the receiving end; The data packet includes: a field identifying the context of the data stream, a sequence identifier field, and a polymorphic payload field, wherein the polymorphic payload field is configured to select from a variety of predetermined data types and carry data of the corresponding type, wherein the predetermined data types include at least text and images.

2. The method for transmitting streaming data according to claim 1, characterized in that, The process of generating a data packet based on the data to be transmitted and the data stream context to which the data belongs includes: In response to the fact that the data to be transmitted is a newly added text fragment relative to the same data stream context, the text payload is carried in the polymorphic payload field; wherein, the text payload includes incremental text and keyword offsets; In response to the fact that the data to be transmitted is an image, the image payload is carried in the polymorphic payload field; wherein the image payload includes an image identifier, binary data, or a Uniform Resource Locator.

3. The method for transmitting streaming data according to claim 1, characterized in that, The process of generating a data packet based on the data to be transmitted and the data stream context to which the data belongs includes: In response to the data to be transmitted being an action to be performed, the execution action payload is carried in the polymorphic payload field; wherein, the execution action payload includes an action identifier, an action name, and an initial state; In response to the data to be transmitted being an action status update, the execution status update load is carried in the polymorphic load field; wherein, the execution status update load includes an action identifier and the updated status.

4. The method for transmitting streaming data according to claim 1, characterized in that, The method for transmitting streaming data includes: Maintain an independent sequence number counter for the data stream context to which the data packet belongs; The step of sending data to the receiving end based on the data packet includes: When sending data to the receiving end, an incrementing sequence number is obtained from the sequence number counter corresponding to the data stream context, and the sequence number is filled into the sequence identifier field.

5. The method for transmitting streaming data of claim 1, wherein, The method for transmitting streaming data includes: Once all data packets in a data stream have been sent, an end signal is sent to the receiving end. In response to the confirmation message returned by the receiving end, a connection disconnection operation is performed; If the confirmation message is not received within the preset timeout period, the preset timeout processing operation will be executed.

6. The method for transmitting streaming data according to claim 1, characterized in that, The step of sending data to the receiving end based on the data packet includes: In response to a pause command sent by the receiving end, data transmission to the receiving end is paused; In response to the recovery command that restores the receiving end's processing capability, data transmission to the receiving end resumes.

7. The method for transmitting streaming data of claim 6, wherein, The step of pausing data transmission to the receiving end in response to a pause command sent by the receiving end includes: In response to a pause command sent by the receiving end and the buffer queue is full, the data packets that overflow the buffer queue are stored in a temporary queue; wherein, the buffer queue is a buffer queue with a fixed capacity set up by the sending end. The recovery command in response to the restoration of the receiving end's processing capability, resuming the transmission of data to the receiving end, includes: In response to a recovery command that restores the receiving end's processing capability, data transmission from the buffer queue is resumed, and data in the temporary queue is transferred to the buffer queue.

8. The method for transmitting streaming data of claim 1, wherein, After sending data to the receiving end, the method for transmitting streaming data further includes: Receive an acknowledgment message sent by the receiving end; wherein the acknowledgment message includes a single successfully processed sequence number and / or a range of sequence numbers.

9. The method for transmitting streaming data of claim 1, wherein, The fields that identify the data stream context include an agent identifier and a chain identifier, wherein the agent identifier is used to distinguish different AI agents, and the chain identifier is used to distinguish different data streams under the same AI agent.

10. A vehicle characterized by comprising: include: Multiple AI agents, which perform inference tasks and generate streaming data; A display unit is used to display the reasoning process of the artificial intelligence agent; A data transmission device, the data transmission device being configured as a sending end to perform a method for transmitting streaming data as described in any one of claims 1-9 above, to transmit data between the artificial intelligence agent and the display unit.

Images