Multicast packet processing method, apparatus and system, vehicle, and storage medium

Abstract

The present application relates to the technical field of Internet of Things, and specifically discloses a multicast packet processing method, apparatus and system, and a vehicle. The method comprises: a first host receives a packet transmitted from a server host via multicast; performing protocol analysis and deserialization processing on the multicast packet to obtain topic information; searching a service subscription table on the basis of the topic information to determine whether a second host subscribes to the topic information, wherein the second host and the first host are located in the same multicast group; and if yes, transmitting the topic information to the second host. In the method, the multicast packet is prevented from being transmitted to the second host, thereby effectively reducing the load pressure of the second host, and avoiding CPU occupation, communication blockage and even downtime caused by transmitting and receiving a multicast packet by a resource-constrained chip. The method saves transmission resources, and improves the transmitting efficiency of multicast packets.

Description

Multicast message processing method, device, system, vehicle and storage medium

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the China Patent Office on February 1, 2024, with application number 202410150460.6 and invention name “A multicast message processing method, device, system and vehicle”, the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The present application relates to the field of Internet of Things technology, and in particular to a multicast message processing method, device, system, vehicle and storage medium. Background Art

[0004] With the development of intelligent connected technologies, more and more fields are beginning to experiment with communication architectures based on the DDS standard. DDS is a data-centric communication model approved by the International Organization for Standardization, and RTPS is an industrial Ethernet standard protocol that implements the DDS architecture. However, the implementation of the DDS standard can lead to problems such as high load and high bandwidth usage.

[0005] For example, when the vehicle service platform sends instructions based on the DDS model, and the instructions are UDP messages based on the RTPS protocol, when there are multiple controller access points in the instance, RTPS will default to sending UDP messages in multicast mode. According to the characteristics of multicast, as long as they are in the same multicast group, all IP clients will receive the routed UDP messages. If a large number of instructions are multicasted at the same time, there will be a large number of UDP messages on the multicast route. For some embedded devices connected to the network, it will cause high chip load, communication congestion, and even lead to CPU fullness, downtime and other problems. Summary of the Invention

[0006] In view of this, the present application provides a multicast message processing method, device, system, vehicle and storage medium to solve the problem of high load and full transmission resource occupancy caused by multicast sending of RTPS messages.

[0007] In a first aspect, the present application provides a multicast message processing method, which is applied to a first host, the method comprising: the first host receives a multicast message sent from a server host; performing protocol parsing and deserialization processing on the multicast message to obtain topic information; searching in a service subscription table according to the topic information whether a second host subscribes to the topic information, wherein the second host and the first host are in the same multicast group; if so, sending the topic information to the second host.

[0008] The first host is a resource-rich chip, and the second host is a resource-constrained chip.

[0009] Optionally, the multicast message is an RTPS message.

[0010] In combination with the first aspect, in a possible implementation, the multicast message is subjected to protocol parsing and deserialization processing to obtain topic information, including: performing three-layer protocol parsing on the multicast message to generate a User Datagram Protocol UDP data packet, the UDP data packet including a data segment; and deserializing the data segment in the UDP data packet to obtain topic information.

[0011] In combination with the first aspect, in another possible implementation, before receiving the multicast message sent by the server host multicast, it also includes: the first host sends an Internet Group Management Protocol report message to the server host and the second host, and the Internet Group Management Protocol report message is used to add the first host to the multicast group; based on the Internet Group Management Protocol report message, a correspondence between the multicast group and the multicast source is generated between the server host, the first host and the second host.

[0012] In combination with the first aspect, in another possible implementation, after sending the Internet Group Management Protocol report message to the server host and the second host, it also includes: the first host receives the Simple Participant Discovery Protocol SPDP message sent from the server host; and performs Simple Participant Discovery Protocol verification with the server host based on the SPDP message.

[0013] In combination with the first aspect, in another possible implementation, after sending the Internet Group Management Protocol report message to the server host and the second host, it also includes: the first host sends a Simple Endpoint Discovery Protocol SEDP message to the server host and the second host; establishing a connection between the first host and the server host according to the SEDP message, and establishing a connection between the first host and the second host.

[0014] In conjunction with the first aspect, in another possible implementation, the first host includes an upstream interface and a downstream interface, wherein the number of the upstream interface and the number of the downstream interface is one or more.

[0015] Receiving a multicast message sent from a server host includes: the first host receiving the multicast message sent from the server host through an upstream interface.

[0016] Sending the topic information to the second host includes: the first host sending the topic information to the second host through the downstream interface.

[0017] In combination with the first aspect, in another possible implementation, the above method also includes: if the multicast group also includes a third host, and the third host establishes a connection with the first host, then searching in the service subscription table based on the topic information whether the third host subscribes to the topic information; if subscribed, the topic information is sent to the third host.

[0018] In the second aspect, the present application also provides a multicast message processing method, which includes: receiving a multicast message sent from a server host; performing protocol parsing and deserialization processing on the multicast message to obtain topic information; searching in a service subscription table based on the topic information whether the second host subscribes to the topic information; if so, sending the topic information to the second host.

[0019] In a third aspect, the present application provides a multicast message processing device, the device comprising:

[0020] A receiving module is used to receive multicast messages sent from the server host;

[0021] The processing module is used to perform protocol parsing and deserialization on the multicast message to obtain topic information;

[0022] a search module, configured to search a service subscription table for whether a second host subscribes to the topic information according to the topic information, wherein the second host and the first host are in the same multicast group;

[0023] The sending module is used to send the topic information to the second host when the searching module finds the topic information subscribed by the second host.

[0024] In conjunction with the third aspect, in a possible implementation, the processing module specifically includes:

[0025] The protocol parsing module is used to perform three-layer protocol parsing on the multicast message and generate a User Datagram Protocol (UDP) data packet, which includes a data segment.

[0026] The serialization processing module is used to deserialize the data segments in the UDP data packet to obtain topic information.

[0027] In a fourth aspect, the present application also provides a system on a chip, comprising a memory and a processor, the memory and the processor being connected; computer instructions are stored in the memory; the processor executes the multicast message processing method in the aforementioned first aspect or any embodiment of the first aspect by executing the computer instructions.

[0028] Optionally, the SOC may be a client host or a server host.

[0029] In a fifth aspect, the present application also provides a multicast message processing system, which includes: a server host and at least two client hosts, and the at least two client hosts are located in the same multicast group.

[0030] The at least two client hosts include a first host and a second host, the server host is connected to the first host, and the first host is connected to the second host; the server host sends a multicast message to the first host.

[0031] The first host receives the multicast message, performs protocol parsing and deserialization on the multicast message to obtain the topic information. Based on the topic information, it searches the service subscription table to see whether the second host has subscribed to the topic information. If so, it sends the topic information to the second host.

[0032] The second host receives the topic information sent by the first host.

[0033] Furthermore, in one possible implementation, the at least two client hosts also include a third host, which is connected to the first host. The first host searches a service subscription table to determine whether the third host has subscribed to the topic information. If so, the first host sends the topic information to the third host. The third host receives the topic information sent by the first host.

[0034] In a sixth aspect, the present application also provides a vehicle, which includes the multicast message processing system described in the fourth aspect, and can be used to execute the multicast message processing method in the first aspect or any embodiment of the first aspect.

[0035] In addition, the present application provides a computer-readable storage medium having computer instructions stored thereon, wherein the computer instructions are used to enable a computer or SOC to execute the multicast message processing method described in the first aspect or any corresponding embodiment thereof.

[0036] The multicast message processing method, device, system, vehicle and storage medium provided in this embodiment set a first host between the server host and the second host. Only the first host receives the multicast message from the server host, and parses and determines whether the second host subscribes to the topic information in the multicast message. If subscribed, the topic information in the multicast message is sent to the second host. If the second host does not subscribe, the topic information is discarded to avoid sending the multicast message to the second host, thereby effectively reducing the load pressure of the second host and avoiding the problem of resource-constrained chips sending and receiving multicast messages, resulting in CPU occupation, communication congestion, and even downtime. The method of this embodiment saves transmission resources and improves the efficiency of multicast message sending.

[0037] The technical solution provided in this embodiment runs the method steps of multicast message parsing, subscription search, etc. in a resource-rich chip, such as the first host. The first host is used to transfer the time-consuming deserialization processing from the resource-constrained chip (the second host or the third host) to the resource-rich chip (the first host), and then filter out some unsubscribed messages, thereby effectively reducing the load pressure of the resource-constrained chip. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the specific implementation methods of the present application or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the specific implementation methods or the description of the prior art. Obviously, the drawings described below are some implementation methods of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0039] FIG1 is a schematic diagram of a server host sending a multicast message according to an embodiment of the present application;

[0040] FIG2 is a flow chart of a multicast message processing method provided in an embodiment of the present application;

[0041] 3 is a flow chart of a method for establishing a correspondence between a multicast group and a multicast source according to an embodiment of the present application;

[0042] FIG4 is a block diagram of the internal structure of a client host provided in an embodiment of the present application;

[0043] FIG5 is a schematic diagram of a multicast message processing method provided in an embodiment of the present application;

[0044] FIG6 is a structural block diagram of a message processing device provided in an embodiment of the present application;

[0045] FIG7 is a structural block diagram of another message processing device provided in an embodiment of the present application;

[0046] FIG8 is a schematic structural diagram of a system on a chip (SOC) provided in an embodiment of the present application;

[0047] FIG9 is a structural diagram of a multicast message processing method system provided in an embodiment of the present application;

[0048] FIG10 is a schematic structural diagram of a vehicle provided in an embodiment of the present application. DETAILED DESCRIPTION

[0049] To make the purpose, technical solutions, and advantages of the embodiments of the present application more clear, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without making creative efforts shall fall within the scope of protection of this application.

[0050] The technical solutions of the embodiments of the present application can be applied to industrial fields that build communication models through DDS (Data Distribution Service); involving most autonomous driving software platforms, central computing platforms based on SOA (Service Oriented Architecture) in the context of software-defined cars, as well as aerospace, national defense, and industrial robots.

[0051] In actual industrial production, chip systems that rely on large-scale integrated circuits (LSIs) have a theoretical frequency limit. Furthermore, due to cost factors (the more powerful the chip, the more expensive it is), communication system designers are always faced with resource constraints. Therefore, within a communication system, different hardware can be divided into the following two categories based on resource constraints:

[0052] One is resource-constrained hardware, and the other is resource-abundant hardware. Resource-constrained hardware refers to low-cost, low-computing-power modular chips, while resource-abundant hardware refers to high-cost, high-computing-power dedicated chips.

[0053] Currently, the vehicle service platform is based on the DDS model and sends instructions, such as UDP (User Datagram Protocol) messages of the RTPS (Real-time Publish-Subscribe) protocol. When multiple clients or server hosts are connected to the network instance, RTPS will use multicast to send UDP messages by default. Due to the characteristics of multicast, as long as they are in the same multicast group, all IP addresses will receive the routed UDP messages. If a large number of instructions are input to the client at the same time, there will be a large number of messages on the multicast route.

[0054] For example, as shown in Figure 1, a scenario in which a server host multicasts an RTPS message includes the server host and multicast group 1, where multicast group 1 includes multicast hosts a, b, and c. The server host sends the RTPS message to multicast hosts a and c via multicast group 1. Multicast hosts a and c communicate with each other via Ethernet.

[0055] In systems communicating over Ethernet, network RTPS messages are typically forwarded through hardware such as switches and routers to the SOC (system on chip). Each multicast host can be considered an SOC. After receiving the RTPS message, the SOC parses and deserializes it through the protocol stack and converts it into a signal usable by the application layer. This process consumes a large amount of CPU resources, especially when resource-rich chips and resource-constrained chips are in the same intercommunication system and exchanging information with each other. The CPU of the resource-constrained chip often has difficulty carrying the excessive bandwidth on the Ethernet, resulting in high chip load, communication congestion, CPU saturation, and even system downtime.

[0056] The technical solution provided by the embodiments of this application stems from the problems encountered in the deployment and implementation of the DDS model on the SDA platform. Currently, the intelligent driving, cockpit, domain control, TBOX and other chips are in the same ring network, and the data sharing pool of the DDS model uses multicast to send notifications (notify messages) under multi-port subscription. Due to the performance differences between each chip, some resource-constrained chips will encounter high load problems. This application solves such problems by designing a virtual data middle platform at the software level.

[0057] This embodiment provides a multicast message processing method to address the technical problem of resource-constrained chips saturating their CPU resources, which can even cause system downtime. It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system, such as a set of computer-executable instructions. Furthermore, although the flowcharts illustrate a logical sequence, in some cases, the steps shown or described may be executed in a different order than that illustrated or described.

[0058] FIG2 is a multicast message processing method provided by an embodiment of the present application. As shown in FIG2 , the method can be applied to a client host, such as a first host, which establishes a persistent connection with a server host. The multicast message processing method includes:

[0059] Step 101: Receive a multicast message sent from a server host.

[0060] Specifically, the first host includes an upstream interface, and uses the upstream interface to receive a multicast message sent by the server host. The multicast message carries a data message, and the data message includes topic information, and the purpose is to send the multicast message to the second host, wherein the second host and the first host belong to the same multicast group.

[0061] Among them, the server host sends a multicast message, specifically including: the server host determines the number of the opposite IP address through the notification information. If the number of the notified opposite IP address is greater than 1, the server host sends the multicast message in the form of multicast, and the destination address of the receiving end is the multicast address. The multicast message is forwarded through the route to reach the first host. After the handshake is passed, the multicast message of the next stage is still sent to the multicast address in the form of multicast.

[0062] Optionally, the multicast message is an RTPS message.

[0063] Step 102: Perform protocol parsing and deserialization processing on the multicast message to obtain topic information.

[0064] Specifically, after receiving the multicast message, the first host first performs Layer 3 protocol parsing on the multicast message to generate a User Datagram Protocol (UDP) data packet, which includes a data segment; then, the first host deserializes the data segment in the UDP data packet to obtain topic information, wherein the topic information includes the transmitted data.

[0065] Step 103: Search the service subscription table based on the topic information to determine whether the second host has subscribed to the topic information.

[0066] The message content subscribed by each client host is pre-set in the service subscription table, such as: the correspondence between the topic information subscribed by the client host and the data message. Before step 101, the client host subscribes to the service information from the server host, and the server host establishes a service subscription table based on the subscription service information. The service subscription table can be a key-value table, and the key in the key-value table is the client host identifier, such as the first host. The value in the key-value table is the topic information, and the topic information includes data data, such as data 1 (data1). The service subscription table is generated after the client host (such as the second host, the third host, etc.) registers the topic information with the first host using the downstream interface, and is stored on the first host side.

[0067] In step 103 , the first host searches the service subscription table based on the topic information to determine whether the second host has subscribed to the topic information. For example, based on the topic information, it can be determined whether the second host has subscribed to data 1 . If yes, step 104 is executed.

[0068] In this embodiment, the first host is resource-rich hardware; the second host is resource-constrained hardware.

[0069] Step 104: Send the topic information to the second host.

[0070] In one implementation, the first host sends the topic information to the second host via a downstream interface. Specifically, the first host may send the topic information to the second host via Ethernet, wherein the topic information includes the data 1.

[0071] If step 103 determines that the topic information is not subscribed in the service subscription table, the topic information is discarded.

[0072] Similarly, assuming that there are other hosts in the multicast group, for example, a third host, the third host is connected to the first host but not to the server host, and the third host is a resource-constrained chip, then the above method further includes:

[0073] The first host searches the service subscription table based on the topic information to determine whether the third host has subscribed to the topic information. If the third host has subscribed to the topic information, the first host sends the topic information to the third host. The specific search method is the same as the method for searching whether the second host has subscribed to the topic information in step 103, and will not be further described in this embodiment.

[0074] The method provided in this embodiment sets a first host between a server host and a second host. Only the first host receives multicast messages from the server host, and parses and determines whether the second host subscribes to the topic information in the multicast message. If it subscribes, the topic information in the multicast message is sent to the second host. If the second host does not subscribe to the topic information, the first host discards it to avoid sending the multicast message to the second host, thereby effectively reducing the load pressure on the second host and avoiding the problem of resource-constrained chips sending and receiving multicast messages, resulting in CPU occupation, communication congestion, and even downtime. This method saves transmission resources and improves the efficiency of multicast message sending.

[0075] It should be noted that the method provided in this embodiment can be implemented by a processing module or processing unit, which is set or integrated on the first host. Optionally, the processing module or processing unit can be implemented by software, hardware, or a combination of software and hardware.

[0076] Optionally, the processing module or processing unit may be a proxy, such as a routing proxy (Router Proxy) module or a routing proxy device.

[0077] In some embodiments, as shown in FIG3 , before step 101, receiving a multicast message sent by a server host via multicast, the method further includes:

[0078] Step 1001: A first host sends an Internet Group Management Protocol report message to a server host and a second host, where the Internet Group Management Protocol report message is used to add the first host to a multicast group.

[0079] The Internet Group Management Protocol (IGMP) is a protocol in the TCP / IP protocol suite responsible for IPv4 multicast member management. Optionally, the IGMP is the IGMPV3 protocol. The protocol report message is used to inform the server host of the relationship among the second host and the third host.

[0080] Step 1002: The first host generates a correspondence between multicast groups and multicast sources among the server host, the first host, and the second host according to the Internet Group Management Protocol report message.

[0081] In one correspondence, the first host establishes a persistent connection with the server host, and the first host establishes Ethernet connections with the second host and the third host, and the first host, the second host, and the third host are in the same multicast group. The second host and the third host are not directly connected to the server host.

[0082] Optionally, establishing a connection relationship between the above-mentioned server host and the first host to the third host specifically includes: the first host receives an SPDP (Simple Participant Discovery Protocol) message sent from the server host; and performing a simple participant discovery protocol verification with the server host based on the SPDP message.

[0083] In addition, establishing a long connection relationship also includes: the first host sends a SEDP (Simple Endpoint Discovery Protocol) message to the server host and the second host, and establishes a connection between the first host and the server host according to the SEDP message, and establishes a connection between the first host and the second host.

[0084] In this embodiment, the first host is connected as a routing proxy between the server host and the second host and the third host to provide multicast messages for the second host and the third host. Before forwarding the multicast messages from the server host, it is first checked whether each host has subscribed to the topic information. Data is only sent to the second host or the third host that has subscribed to the topic information, thereby avoiding resource-constrained chips, such as the second host and the third host sending and receiving instructions from the server host, which causes the CPU to be occupied and congested.

[0085] In a specific embodiment, as shown in FIG4 , the first host includes an ECU (Electronic Control Unit) 410 , a logic decision module 420 and a protocol stack 430 within the communication system.

[0086] ECU 410 is connected to at least one sensor and is used to receive external signals collected by the at least one sensor. The signals are transmitted via input / output interfaces and analog-to-digital converters, and processed by the inherent program in RAM and the microcontroller to generate a raw signal S1 (signal 1). The raw signal S1 is then transmitted to the logic decision module 420. After receiving the raw signal S1, the logic decision module 420 processes, reorganizes, and filters the raw signal S1 according to the strategy, converting the raw signal S1 into an analog signal S2, and transmitting the analog signal S2 to the protocol stack 430. After receiving the analog signal S2, the protocol stack 430 converts the analog signal S2 into data that conforms to the protocol stack through a programming interface, including deserialization. Finally, the data processed by the protocol stack 430, such as topic information, is transmitted to other hosts via Ethernet.

[0087] Among them, the protocol stack establishes a long connection with the communication peer participant entity that subscribes to the service through the protocol stack, and sends the serialized data in the form of Ethernet messages, as shown in Figure 5. The details are as follows:

[0088] 1) The server host s regularly sends SPDP packets to the multicast group, which contains client hosts a, b, and c.

[0089] Among them, client hosts a, b, and c are also called multicast hosts a, b, and c.

[0090] 2) Client hosts a, b, and c periodically send SPDP messages to the multicast group. The server (e.g., server host s) and client hosts a, b, and c in the same domain detect the presence of the participating entity. The SPDP message contains domain information, the process name, the participating entity, and notifies the peer of the next phase's destination address.

[0091] 3) The server host s determines the destination address of the SEDP message to be sent through the notification information. The notification information includes the following two situations.

[0092] Scenario 1: The number of advertised peer IP addresses is 1. In this case, the SEDP message is unicast, and the destination IP address is the peer IP address. After the handshake between server host s and multicast host a is completed, server host s sends a multicast message, such as an RTPS message, to the destination IP address in unicast form.

[0093] Scenario 2: The number of announced peer IP addresses is greater than 1. In this case, the SEDP message is sent in multicast form, and the destination address is the multicast address. The multicast message is forwarded through routing to client hosts a, b, and c. After the handshake is successful, the next stage RTPS message is still sent in multicast form to the multicast address.

[0094] In this embodiment, the main explanation is for "Scenario 2". In "Scenario 2", since the client hosts a, b, and c have all shaken hands with the server host s, the server's topic information is sent to the multicast address in multicast form, and the server host s sends a data message (the message includes the topic information). According to the configuration of the multicast routing table, the client hosts a, b, and c in the same multicast group will receive the data, but not all client hosts have subscribed to the topic information. Therefore, the data message will first reach the client host a access port. The client host a goes through the three-layer protocol and is finally deserialized by the RTPS protocol stack of the SOC. After parsing the topic information of the data message, it determines whether to filter the data message or forward the data message to the client host b or the client host c. Among them, the data message is also data data, such as data1.

[0095] As shown in Figure 5, in this simple tree network topology, client hosts b and c are not directly connected to server host s. Client host a is placed as a router proxy device between server host s and client hosts b and c. On the one hand, client host a can act as a router proxy device to establish connections with downstream client hosts b and c, collect request or callback messages, and aggregate the messages and notify them to the server device.

[0096] On the other hand, when a large number of multicast packets originating from servers or server nodes are present on the network, client host a can proxy the server to query topic information subscribed to by downstream members, maintain multicast group membership, and filter packets with source addresses in the multicast group member blacklist based on the multicast source address. From the client's perspective, the Router Proxy device is the server host or server node, simplifying packet traffic on downstream links and reducing bandwidth burden.

[0097] In this embodiment, client host a establishes communication with server host s to form multicast domain 1. Client host a then establishes communication with a client host group (e.g., including hosts b and c) to form multicast domain 2. In multicast domain 2, client host a receives topic registration information from each member host in the client host group to form a service subscription table.

[0098] The client host a receives a multicast message sent from the server host s; performs protocol parsing and deserialization on the multicast message to obtain topic information; searches the service subscription table for a member host in the client host group based on the topic information to determine whether a member host has subscribed to the topic information; finds that the host subscribing to the topic information is the second host, and if the number of second hosts is unique, unicasts the topic information to the second host; if there are multiple client hosts subscribing, the topic information is multicasted within the second multicast domain. This method reduces the number of multicast messages received by the second host, thereby effectively reducing the load pressure on the second host, avoiding CPU occupation, communication blockage, and even downtime caused by resource-constrained chips sending and receiving multicast messages, and saves transmission resources and improves the efficiency of sending multicast messages.

[0099] The method provided in this embodiment is described below with examples.

[0100] RTPS message transmission involves multiple participant entities. In the client / s communication model, the participants within the system can be divided into server participants and client participants. As shown in Figure 5, a link establishment relationship is:

[0101] Ethernet access server node 1: As a server participant, it creates a server communication publishing entity and publishes services externally. The server node 1 is deployed on the server host s.

[0102] Ethernet access client node 1: a client participant, creates a client communication subscription entity, and receives services published by the Ethernet access server. The client node 1 is deployed on multicast host a (referred to as "host a" for short).

[0103] Ethernet access client node 2: a client participant that creates a client communication subscription entity and receives services published by the Ethernet access server. This client node 2 is deployed on multicast host b (referred to as "host b" for short).

[0104] Ethernet access client node 3: a client participant, creates a client communication subscription entity, and receives services published by the Ethernet access server. This client node 3 is deployed on multicast host c (referred to as "host c" for short).

[0105] Among them, host a can be used as a proxy node / module Router proxy; host a can be the first host in the above embodiment.

[0106] After configuring the server host and client host, connections are established between each host and the server host. One implementation utilizes an Internet Group Management Protocol, such as IGMPV3. Server host s, host a, host b, and host c send IGMPV3 report messages to adjacent routing nodes within the network segment. These IGMPV3 report messages add the hosts to the same multicast group and include information about the multicast sources from which the hosts wish to receive data.

[0107] Using the IGMPv3 protocol's filtering mode (INCLUDE / EXCLUDE) for multicast sources, hosts b and c filter RTPS packets from multicast source server host s. The correspondence between multicast groups and source lists can be simply expressed as (b, INCLUDE, (s, a)), (c, INCLUDE, (s, a)), (a, INCLUDE, (b, c, s)), and (s, INCLUDE, (a, b, c)).

[0108] In this example, (b, INCLUDE, (s, a)) indicates that host b only receives multicast packets whose sources are server host s and host a. (c, INCLUDE, (s, a)) indicates that host c only receives multicast packets whose sources are server host s and host a. (a, INCLUDE, (b, c, s)) indicates that host a only receives multicast packets whose sources are hosts b and c and server host s. (s, INCLUDE, (a, b, c)) indicates that server host s only receives multicast packets whose sources are hosts a, b, and c.

[0109] Optionally, a specific implementation method of establishing the connection relationship between the multicast group and the multicast source is: establishing the connection relationship based on a multicast filtering protocol and a simple participant discovery protocol.

[0110] Specifically, hosts a, b, and c send SPDP messages to server host s. Correspondingly, server host s receives SPDP messages from hosts a, b, and c. However, since hosts b and c filter the multicast source of the server host, server host s only establishes a connection with host a through the participant discovery protocol.

[0111] Similarly, host a receives SPDP messages from host b and host c, and host b and host c also receive SPDP messages from host a. Therefore, host a discovers the participants through the protocol with hosts b and c respectively.

[0112] The process of establishing a persistent connection also includes: server host s and host a exchanging SEDP messages. Specifically, host a exchanges SEDP messages with host b. After verification, a persistent connection is established. After the persistent connection is established, the network topology shown in Figure 5 is obtained. Client hosts b and c are not directly connected to server host s. Client host a acts as a router proxy device between server host s and client hosts b and c, performing functions such as message forwarding and topic information subscription and lookup.

[0113] In this embodiment, two types of interfaces are defined in host a, namely upstream interface and downstream interface.

[0114] The upstream interface refers to the Router Proxy device that proxies client participants to subscribe to the server host's topic within the same domain. This interface performs the client's writer / reader behavior, sends client heartbeat packets and request messages, and receives the server's response messages and data messages, such as notification (NTF) messages.

[0115] Downstream interface: refers to the function of the Router Proxy host to publish topics within the domain. This interface performs the server-side writer / reader behavior. When the client establishes a connection with it, it receives the topic registered by the client host. During the communication process, it receives the client request request, forwards the request request to the upstream interface, and sends the response and NTF message to the client.

[0116] When server host s sends an RTPS message, if the number of multicast groups "other" in its domain is greater than or equal to 1, multicast transmission is performed by default. In this example, client hosts b and c use the IGMPV3 protocol to filter out multicast messages from multicast source server host s. Therefore, the RTPS message is not sent to hosts b and c, but only to host a. This effectively reduces the network port bandwidth of hosts b and c.

[0117] The RTPS message includes at least one of a SEDP message, an SPDP message and a data message.

[0118] Correspondingly, in the above step 101, when host a (Router Proxy device) obtains the RTPS message from the server host s through the upstream interface, the RTPS message is parsed through the three-layer protocol to reach the RTPS protocol stack. The RTPS protocol stack then unpacks the original UDP message to obtain the data message, deserializes the data segment content in the data message, obtains the topic information in the data segment, and executes the method flow of the above step 102.

[0119] Then, host a determines whether hosts b and c have subscribed to the topic information based on the service subscription table previously registered by client hosts b and c using the downstream interface, and decides whether to forward the topic information. If so, it sends it to host b or host c in unicast mode. Otherwise, it discards the topic information because hosts b and host c have not subscribed to the information.

[0120] Among them, host b and host c are resource-constrained chips, and host a and server host s are resource-rich chips.

[0121] In addition, in this embodiment, host a may be the first host in the aforementioned embodiment, host b may be the second host in the aforementioned embodiment, and host c may be the third host in the aforementioned embodiment.

[0122] In this embodiment, host a (Router Proxy device) runs in a resource-rich chip, and host a cleverly separates the multicast RTPS message from the messages that need to be deserialized by all members in the multicast group. A Router Proxy device is used to transfer the time-consuming deserialization process from the restricted chip to the redundant chip, and then some unsubscribed messages, that is, topic information, are filtered out, thereby effectively reducing the load pressure on the resource-constrained chip.

[0123] Optionally, the host a can use a separate MCU as a Router Proxy, retaining only the upstream and downstream functional interfaces and protocol stack parsing part of the Router Proxy, so that its functions are completely separated from the services on the SOC, thereby transforming it into a simple routing unit.

[0124] The method provided in this embodiment has the following beneficial effects:

[0125] 1. The vehicle adopts a DDS-based Ethernet communication architecture, which has the advantages of high bandwidth and high reliability. It can transmit high-precision pictures and videos and support autonomous driving data transmission based on vision, ultrasound, millimeter-wave radar, etc.

[0126] 2. The client is topologically grouped through the IGMPV3 protocol to achieve multicast isolation, effectively reducing the network bandwidth of downstream nodes accessing the ring network through the data middle station, and solving the load problem of resource-constrained chips.

[0127] 3. In the embodiment of the present application, after receiving the multicast message, the multicast message is subjected to protocol parsing and deserialization processing to obtain topic information, thereby achieving accurate routing of the client, meeting the scalability requirements of small devices, and effectively reducing hardware costs.

[0128] This embodiment also provides a multicast message processing device for implementing the above-mentioned embodiments and optional implementations. Details already described will not be repeated here. As used below, the term "module" may refer to a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation using hardware, or a combination of software and hardware, is also possible and contemplated.

[0129] This embodiment provides a multicast message processing device, as shown in Figure 6, which includes a receiving module 601, a processing module 602, a search module 603, and a sending module 604. In addition, the device may also include more or fewer modules, which is not limited in this embodiment.

[0130] The receiving module 601 is configured to receive a multicast message sent from a server host.

[0131] The processing module 602 is used to perform protocol parsing and deserialization processing on the multicast message to obtain topic information.

[0132] The search module 603 is configured to search a service subscription table according to the topic information to determine whether the second host has subscribed to the topic information, wherein the second host and the first host are in the same multicast group.

[0133] The sending module 604 is configured to send the topic information to the second host when the searching module 603 finds that the second host subscribes to the topic information.

[0134] In addition, the sending module 604 is further configured to discard the topic information when the searching module 603 determines that the second host has not subscribed to the topic information.

[0135] Optionally, as shown in FIG7 , the processing module 602 specifically includes: a protocol parsing module 6021 and a serialization processing module 6022 .

[0136] The protocol parsing module 6021 is used to perform layer 3 protocol parsing on the multicast message to generate a User Datagram Protocol (UDP) data packet, wherein the UDP data packet includes a data segment;

[0137] The serialization processing module 6022 is used to deserialize the data segment in the UDP data packet to obtain the topic information.

[0138] Optionally, in one embodiment, before the receiving module 601 receives the multicast message sent by the server host, the sending module 604 is further configured to send an Internet Group Management Protocol report message to the server host and the second host.

[0139] The processing module 602 is further configured to generate a correspondence between the multicast group and the multicast source between the server host, the first host, and the second host according to the Internet Group Management Protocol report message.

[0140] Optionally, in another embodiment, the receiving module 601 is further used to receive an SPDP message sent from the server host; the processing module 602 is further used to perform a simple participant discovery protocol verification with the server host based on the SPDP message.

[0141] Optionally, in another embodiment, the sending module 604 is further used to send SEDP messages to the server host and the second host; the processing module 602 is further used to establish a connection between the first host and the server host according to the SEDP message, and to establish a connection between the first host and the second host.

[0142] In addition, the receiving module 601 is further configured to receive the multicast message sent by the server host through the upstream interface.

[0143] The sending module 604 is further configured to send the topic information to the second host via the downstream interface.

[0144] Optionally, in another embodiment, the search module 603 is further configured to search the service subscription table for whether a third host subscribes to the topic information according to the topic information; and the third host and the first data belong to the same multicast group.

[0145] The sending module 604 is further configured to send the topic information to the third host if the searching module 603 searches and determines that the third host subscribes to the topic information.

[0146] The multicast message processing device in this embodiment is presented in the form of functional units. These units refer to ASIC circuits, processors executing one or more software or fixed programs, memory, and / or other devices that can provide the aforementioned functions. Further functional descriptions of each of these modules and units are the same as those in the corresponding embodiments above and are not repeated here.

[0147] The device provided in this embodiment uses a search module to search the service subscription table to see whether the resource-constrained second host has subscribed to the topic information, and when it is determined that it has subscribed, the topic information is sent to the second host, thereby avoiding the server host from sending the multicast message to the second host and executing the query processing process on the first host. This can effectively reduce the load pressure on the second host and avoid the problem of resource-constrained chips sending and receiving multicast messages, which leads to CPU occupation, communication congestion, and even downtime.

[0148] Please refer to Figure 8, which is a structural diagram of a system on chip SOC provided in an optional embodiment of the present application. As shown in Figure 8, the system on chip SOC includes: one or more processors 10, a memory 20, and interfaces for connecting various components, such as an upstream interface and a downstream interface 30.

[0149] The various components are interconnected using different buses and may be mounted on a common motherboard or in other ways as needed. The processor may process instructions executed within the electronic device, including instructions stored in or on the memory for displaying graphical information of the GUI on an external input / output device (such as a display device coupled to the interface).

[0150] In some alternative embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple storages if desired. Similarly, multiple SOCs or multiple client hosts can be connected, with each host device providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multi-processor system). FIG8 shows a single processor 10 as an example.

[0151] The processor 10 may be an electronic control unit (ECU). The processor 10 may also include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CPLD), a field programmable gate array (FPGA), a general purpose array logic (GAL), or any combination thereof.

[0152] The memory 20 stores instructions that can be executed by at least one processor 10, so that the at least one processor 10 executes the multicast message processing method shown in the above embodiment.

[0153] The memory 20 may include a program storage area and a data storage area. The program storage area may store an operating system and at least one application required for a function; the data storage area may store data generated based on the use of the electronic device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state memory device. In some optional embodiments, the memory 20 may optionally include a memory remotely located relative to the processor 10, and such remote memory may be connected to the electronic device via a network.

[0154] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0155] In addition, the SOC may further include an input / output device. The processor 10, the memory 20 and the input / output device may be connected via a bus or other means, and FIG8 takes the bus connection as an example.

[0156] Optionally, the input device can receive input digital or character information and generate key signal input related to user settings and function control of the electronic device, such as a touch screen, a keypad, a mouse, a trackpad, a touch pad, an indicator stick, one or more mouse buttons, a trackball, a joystick, etc. The output device may include a display device, an auxiliary lighting device (e.g., an LED), and a tactile feedback device (e.g., a vibration motor). The above-mentioned display device includes but is not limited to a liquid crystal display, a light emitting diode, a display, and a plasma display. In some optional embodiments, the display device can be a touch screen.

[0157] In addition, it should be noted that the above-mentioned SOC (System on Chip) can be a client host, such as the first host, the second host and the third host; or the SOC can also be a server host, or a service node.

[0158] 9 , a multicast message processing system is provided in this embodiment. The system includes a server host and at least two client hosts, and the at least two client hosts are located in the same multicast group.

[0159] The at least two clients include a first host, a second host, and a third host, and the first host, the second host, and the third host belong to the same multicast group. The server host is connected to the first host, and the first host is connected to the second host and the third host.

[0160] Among them, the server host sends a multicast message to the first host, the first host receives the multicast message, performs protocol parsing and deserialization on the multicast message, obtains the topic information, and searches the service subscription table for whether the second host subscribes to the topic information according to the topic information. If so, the topic information is sent to the second host.

[0161] The second host receives the topic information sent by the first host.

[0162] Optionally, the first host is host a and the second host is host b.

[0163] In some implementations, the first host further searches the service subscription table to determine whether the third host has subscribed to the topic information. If so, the first host sends the topic information to the third host.

[0164] In addition, this embodiment also provides a vehicle, as shown in FIG10 , which includes the multicast message processing system shown in FIG9 .

[0165] The embodiments of the present application also provide a computer-readable storage medium. The above-mentioned method according to the embodiments of the present application can be implemented in hardware, firmware, or implemented as a computer code that can be recorded on a storage medium, or downloaded via a network and originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware.

[0166] The storage medium may be a magnetic disk, an optical disk, a read-only memory, a random access memory, a flash memory, a hard disk, or a solid-state drive, etc.; optionally, the storage medium may also include a combination of the aforementioned types of memory. It is understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the methods shown in the above embodiments are implemented.

[0167] Although the embodiments of the present application have been described with reference to the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present application, and such modifications and variations shall fall within the scope defined by the appended claims.

Claims

1. A multicast message processing method, characterized in that: Applied to a first host, the method includes: Receive multicast messages sent from the server host; Perform protocol parsing and deserialization processing on the multicast message to obtain topic information; Searching, in a service subscription table according to the topic information, whether a second host has subscribed to the topic information, wherein the second host and the first host are in the same multicast group; If yes, the topic information is sent to the second host.

2. The method according to claim 1, characterized in that The performing protocol parsing and deserialization processing on the multicast message to obtain topic information includes: Performing layer 3 protocol parsing on the multicast message to generate a User Datagram Protocol (UDP) data packet, wherein the UDP data packet includes a data segment; Deserialize the data segment in the UDP data packet to obtain the topic information.

3. The method according to claim 2, characterized in that Before receiving the multicast message from the server host, it also includes: Sending an Internet Group Management Protocol report message to the server host and the second host, wherein the Internet Group Management Protocol report message is used to add the first host to a multicast group; A correspondence between multicast groups and multicast sources between the server host, the first host, and the second host is generated according to the Internet Group Management Protocol report message.

4. The method according to claim 3, characterized in that After sending the Internet Group Management Protocol report message to the server host and the second host, the method further includes: Receiving a Simple Participant Discovery Protocol (SPDP) message sent from the server host; Perform a simple participant discovery protocol verification with the server host according to the SPDP message.

5. The method according to claim 4, characterized in that After sending the Internet Group Management Protocol report message to the server host and the second host, the method further includes: Sending a Simple Endpoint Discovery Protocol (SEDP) message to the server host and the second host; A connection is established between the first host and the server host according to the SEDP message, and a connection is established between the first host and the second host.

6. The method according to any one of claims 1 to 5, characterized in that The first host includes an upstream interface and a downstream interface; The receiving of a multicast message sent from the server host includes: Receiving the multicast message sent by the server host through the upstream interface; The sending the topic information to the second host includes: The topic information is sent to the second host through the downstream interface.

7. The method according to any one of claims 1 to 5, characterized in that The method further comprises: If the multicast group further includes a third host, and the third host establishes a connection with the first host, searching the service subscription table for whether the third host subscribes to the topic information according to the topic information; If subscribed, the topic information is sent to the third host.

8. A multicast message processing method, characterized in that: The method comprises: Receive multicast messages sent from the server host; Perform protocol parsing and deserialization processing on the multicast message to obtain topic information; Searching, in a service subscription table according to the topic information, whether the second host has subscribed to the topic information; If yes, the topic information is sent to the second host.

9. A multicast message processing device, characterized in that: The device comprises: A receiving module is used to receive multicast messages sent from the server host; A processing module, configured to perform protocol parsing and deserialization processing on the multicast message to obtain topic information; a search module, configured to search a service subscription table for whether a second host has subscribed to the topic information according to the topic information, wherein the second host and the device are in the same multicast group; A sending module is used to send the topic information to the second host when the search module finds that the second host subscribes to the topic information.

10. The device according to claim 9, characterized in that The processing module includes: A protocol parsing module, configured to perform layer 3 protocol parsing on the multicast message to generate a User Datagram Protocol (UDP) data packet, wherein the UDP data packet includes a data segment; The serialization processing module is used to deserialize the data segment in the UDP data packet to obtain the topic information.

11. A system on chip, characterized in that: The system on chip includes a memory and a processor, and the memory and the processor are connected; The memory stores computer instructions; The processor executes the multicast message processing method according to any one of claims 1 to 7 by executing the computer instructions.

12. A multicast message processing system, characterized in that: The system includes: a server host and at least two client hosts, wherein the at least two client hosts are located in the same multicast group; The at least two client hosts include a first host and a second host, the server host is connected to the first host, and the first host is connected to the second host; The server host sends a multicast message to the first host; The first host receives the multicast message, performs protocol parsing and deserialization processing on the multicast message to obtain topic information, searches a service subscription table for the topic information based on the topic information to determine whether the second host subscribes to the topic information, and if so, sends the topic information to the second host; The second host receives the topic information sent by the first host.

13. The system according to claim 12, wherein: The at least two client hosts further include a third host, and the third host is connected to the first host; The first host searches the service subscription table to determine whether the third host has subscribed to the topic information. If so, the first host sends the topic information to the third host.

14. A vehicle, characterized in that: It includes the multicast message processing system as described in claim 12 or 13.

15. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the multicast message processing method according to any one of claims 1 to 7.

Images