Message transmission method, computer device, storage medium and product

Abstract

This application relates to a message transmission method, computer device, storage medium, and product. The message transmission method is executed by a user-space network protocol stack in any container node within a container network environment. The user-space network protocol stack in the container node establishes a communication relationship with the routing control plane through a kernel protocol stack. A mapping relationship is established between the host interface of the user-space network protocol stack and the forwarding interface of the container node. The method includes: receiving a target message; the target message being a traffic message received through a virtual network interface card or a first routing control message sent by the routing control plane; querying the target forwarding table entry corresponding to the destination IP address of the target message in the forwarding table; and transmitting the target message based on the target forwarding table entry. This method utilizes a user-space network protocol stack to perform routing and forwarding functions, avoiding the performance bottleneck of traditional kernel protocol stacks that limits message transmission efficiency and improving message transmission efficiency.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a message transmission method, computer equipment, storage medium, and product. Background Technology

[0002] With the advancement of virtualization technology, container-based simulation platforms have been widely used. However, container-based simulation platforms still rely on the host machine's operating system kernel protocol stack for data forwarding. Due to the performance bottleneck of the kernel protocol stack, they suffer from problems such as low forwarding efficiency and insufficient scalability. Summary of the Invention

[0003] This application provides a message transmission method, computer device, storage medium, and product, which realizes the use of user-space network protocol stack to perform routing and forwarding functions, avoiding the limitation of message transmission efficiency by the performance bottleneck of traditional kernel protocol stack, and improving message transmission efficiency. The technical solution is as follows.

[0004] On one hand, a message transmission method is provided, which is executed by a user-space network protocol stack in a first container node. The first container node is any container node in a container network environment. The container node runs a user-space network protocol stack, a kernel protocol stack, and a routing control plane. The user-space network protocol stack and the routing control plane establish a communication relationship through the kernel protocol stack. A mapping relationship is established between the host interface of the user-space network protocol stack and the forwarding interface of the container node. The method includes: Receive target message; the target message is a traffic message received through a virtual network interface card, or a first routing control message sent by the routing control plane; Search the forwarding table for the target forwarding entry corresponding to the destination IP address of the target packet; The target message is transmitted based on the target forwarding table entry.

[0005] On the other hand, a computer device is provided, the computer device including a processor and a memory, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor to implement the above-described message transmission method.

[0006] On the other hand, a computer-readable storage medium is provided, wherein at least one computer program is stored in the computer program, which is loaded and executed by a processor to implement the above-described message transmission method.

[0007] On the other hand, a computer program product is provided, the computer program product including a computer program stored on a non-transitory computer-readable storage medium, the computer program including program instructions, which, when executed by a computer, cause the computer to execute to implement the message transmission method provided in the various optional implementations described above.

[0008] The message transmission method provided in this application configures a user-space network protocol stack in a container node within a container network environment. It establishes a communication relationship between the user-space network protocol stack and the routing control plane, as well as a mapping relationship between the host interface of the user-space network protocol stack and the forwarding interface of the container node, through a kernel protocol stack. This allows the user-space protocol stack to receive target messages, query the target forwarding table entry corresponding to the destination IP address of the target message in the forwarding table, and then transmit the target message based on the target forwarding table entry. The target message can be a traffic message received through a virtual network interface card (NIC) or a first routing control message sent by the routing control plane. This method utilizes the user-space network protocol stack to perform routing and forwarding functions, avoiding the performance bottleneck of the traditional kernel protocol stack that limits message transmission efficiency and improving message transmission efficiency. Furthermore, the user-space network protocol stack offers greater flexibility and performance advantages, enhancing the scalability of the container network environment.

[0009] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0010] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0011] Figure 1 This invention provides a schematic diagram of the structure of a container network environment according to an exemplary embodiment of the present application. Figure 2 This application illustrates a schematic diagram of the internal structure of a single container node provided as an example. Figure 3 A flowchart of a message transmission method provided in an exemplary embodiment of this application is shown; Figure 4 A flowchart of a message transmission method provided in another exemplary embodiment of this application is shown; Figure 5 This application shows a structural block diagram of a computer device according to an exemplary embodiment. Detailed Implementation

[0012] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of methods consistent with some aspects of this application as detailed in the appended claims.

[0013] This application provides a message transmission method. In a container network environment, by configuring a user-space network protocol stack in each container node, message transmission is transferred from the kernel protocol stack to the user-space protocol stack for execution, thereby improving message forwarding efficiency. The user-space network protocol stack refers to migrating the traditional network protocol stack from kernel space to user space for operation. Message transmission through the user-space network protocol stack can bypass the performance bottleneck of the kernel protocol stack, improve data forwarding efficiency by directly manipulating network data in user space, and provide greater flexibility.

[0014] Figure 1 This application illustrates a schematic diagram of the structure of a container network environment provided in an exemplary embodiment, as shown below. Figure 1 As shown, this container network environment can be built on the host system, and the container network environment can be composed of multiple container nodes. Figure 1 Taking two container nodes as an example, each container node can serve as a basic unit of the network topology, realizing the abstract logic of a single spatial network node. For example, in a satellite network simulation scenario, each container node can correspond to a low Earth orbit (LEO) satellite.

[0015] Container Node is an open-source container engine that allows developers to package network applications and their runtime environments into a lightweight, portable image, which can then be deployed to an operating system, such as Linux. Container Node provides a unified runtime environment, sharing the host machine's operating system and hardware resources, resulting in better utilization of system resources and faster startup and execution speeds. The underlying principle of network isolation between container nodes is the network namespaces provided by the system. Different network namespaces have independent network interface cards, routing tables, and firewall systems, and can also use virtual network cards "veth" (virtual Ethernet) to achieve interconnection between "netns" (network namespaces).

[0016] Intuitively, the process of interconnecting network namespaces using virtual network interface cards (NICs) can be implemented as follows: a pair of virtual NICs is created between the container node and the OVS (Open vSwitch) bridge, with the OVS bridge managing the network links. Furthermore, a pair of virtual NICs (veth1 and veth2) is created between the user-space network protocol stack of the container node and the OVS bridge. In other words, container nodes are connected through a single OVS bridge, meaning the structure of the soft router container and the bridge in the service is a divergent star topology centered on the OVS bridge.

[0017] Figure 2 This application illustrates an exemplary internal structure diagram of a single container node, as shown below. Figure 2 As shown, each container node in the container network environment runs a user-space network protocol stack 210, a kernel protocol stack 220, and a routing control plane 230. The user-space network protocol stack 210 can be implemented as a VPP (Vector Packet Processing) process to provide data plane services to routing nodes. It maintains a Forward Information Base (FIB), which can be statically added manually or obtained synchronously from routing entries in the kernel routing table through communication with the routing control plane, and then iterated through these entries. The user-space protocol stack is characterized by high efficiency, flexibility, scalability, and low latency. High efficiency is reflected in its ability to avoid kernel context switching and the complexity of the kernel protocol stack, resulting in more efficient data processing. Flexibility is reflected in its ability to allow developers to quickly modify and debug in user space, providing greater flexibility and suitability for rapid prototyping and verification. Scalability is reflected in its support for more complex network topologies and protocol stacks, making the network simulation environment easier to expand. Low latency is reflected in its ability to significantly reduce data transmission latency and improve real-time performance by minimizing interaction between kernel space and user space, thus adapting to higher-performance simulation requirements. The routing control plane can be implemented as a Quagga process, responsible for sending and receiving routing packets, parsing and processing routing information, and issuing routing entries; for example... Figure 2 As shown, the user-space network protocol stack 210 and the routing control plane 230 establish a communication relationship through the kernel protocol stack 220. The user-space network protocol stack 210 is configured with a host interface, and a mapping relationship is established between the host interface of the user-space network protocol stack and the forwarding interface of the container node. The host interface mechanism provided by the user-space network protocol stack 210 can directly take over the virtual network card located in the kernel space and bypass the kernel protocol stack to perform packet transmission.

[0018] Based on such Figure 1 The container network environment shown and such Figure 2 As shown in the container node, this application embodiment provides a message transmission method. Figure 3 This application illustrates a flowchart of a message transmission method provided in an exemplary embodiment. This method can be executed by a user-space network protocol stack in a first container node, which is as follows: Figure 1 Any container node in the container network environment shown, such as Figure 3 As shown, the method may include the following steps.

[0019] Step 310: Receive the target message; the target message is either a traffic message received through the virtual network interface card or a first routing control message sent by the routing control plane.

[0020] In the first container node, the user-space protocol stack and the routing control plane establish a communication relationship through the kernel protocol stack. Therefore, the user-space protocol stack can exchange information with the routing control plane through the kernel protocol stack, such as receiving routing control messages or sending routing updates.

[0021] The user-space protocol stack establishes a mapping relationship between the host interface and the forwarding interface between the container nodes. Therefore, the user-space protocol stack can receive and send packets through the host interface, and these packets will eventually be transmitted over the network through the forwarding interface of the container nodes.

[0022] During message transmission, since the user-space protocol stack establishes a connection with the OVS bridge through the virtual network interface card, it can receive traffic messages transmitted from other container nodes in the container network environment or external networks through the OVS bridge. When the routing control plane performs a route update or route decision, it needs to send out routing control information, namely the first routing control information. Accordingly, the user-space protocol stack receives the first routing control information sent by the routing control plane.

[0023] Step 320: Query the target forwarding table entry corresponding to the destination IP address of the target packet in the forwarding table.

[0024] The user-space network protocol stack maintains its own forwarding table. The forwarding entries in this table are used to indicate the forwarding method of the packet. The forwarding entries can contain information such as the next-hop IP (Internet Protocol) address, the outgoing interface, and the routing policy. After receiving the target packet, the user-space network protocol stack can look up the target forwarding entry corresponding to the destination IP address of the target packet in the forwarding table.

[0025] Step 330: Transmit the target message based on the target forwarding table entry.

[0026] Based on the target forwarding table entry retrieved, the user-space network protocol stack will process the target packet accordingly and forward it to the correct next hop or outgoing interface. The transmission processing of the target packet may include, but is not limited to, modifying the packet header information, selecting the correct outgoing interface, and executing routing policies.

[0027] In summary, the message transmission method provided in this application configures a user-space network protocol stack in the container node of the container network environment, establishes a communication relationship between the user-space network protocol stack and the routing control plane through the kernel protocol stack, and establishes a mapping relationship between the host interface of the user-space network protocol stack and the forwarding interface of the container node. This allows the user-space protocol stack to receive the target message, query the target forwarding table entry corresponding to the destination IP address of the target message in the forwarding table, and then transmit the target message based on the target forwarding table entry. The target message can be a traffic message received through a virtual network interface card (NIC) or a first routing control message sent by the routing control plane. This method utilizes the user-space network protocol stack to perform routing forwarding functions, avoiding the performance bottleneck of the traditional kernel protocol stack that limits message transmission efficiency and improving message transmission efficiency. Furthermore, the user-space network protocol stack offers greater flexibility and performance advantages, thus enhancing the scalability of the container network environment.

[0028] In this embodiment, the user-space protocol network protocol stack can transmit traffic packets or first routing control packets sent by the internal routing control plane to the outside, and can also receive second routing control packets sent by the external routing control plane, forward them to the internal routing control plane for parsing and recalculating routes. Figure 4 A flowchart of a message transmission method provided in another exemplary embodiment of this application is shown. This method can be executed by a user-space network protocol stack in a first container node, which is any container node in a container network environment, such as... Figure 4 As shown, the method may include the following steps.

[0029] Step 410: Receive the target message; the target message is a traffic message received through the virtual network card, or a first routing control message sent by the routing control plane.

[0030] Step 420: Query the target forwarding table entry corresponding to the destination IP address of the target packet in the forwarding table.

[0031] Forwarding entries maintained in the user-space network protocol stack can be added manually. For example, specific route entries can be added directly to the user-space network protocol stack's forwarding table using command-line tools or configuration files. Alternatively, they can be synchronized and updated from the kernel routing table of the kernel protocol stack. For instance, when the network topology changes, the routing control plane recalculates routes and sends new route entries to the kernel routing table. The user-space network protocol stack can synchronize the changes in the kernel routing table to maintain consistency between the forwarding table and the routing information in the kernel routing table.

[0032] To establish communication between the kernel protocol stack and the user-space network protocol stack, a router plugin is loaded into the sandbox of the user-space network protocol stack. This plugin interacts with the kernel routing table of the kernel protocol stack to synchronize and update routing information. The router plugin implements a Netlink-based communication mechanism, allowing the user-space network protocol stack to synchronously maintain its own forwarding table based on the routing information sent from the routing control plane to the kernel routing table. This process can be achieved as follows: The user-space network protocol stack detects the kernel routing table of the kernel protocol stack; If the kernel routing table contains a target route entry, the target route entry is obtained through the router plugin. This target route entry is a route entry that the routing control plane recalculates and sends to the kernel routing table when the resolution result indicates a change in link state. Maintain a forwarding table based on the target routing entries.

[0033] The router plugin can periodically or through an event-driven mechanism detect changes in the kernel routing table of the kernel protocol stack. The detection period can be set by relevant personnel based on actual needs, while event-driven detection can trigger a notification when the kernel routing table changes. The router plugin accesses the kernel routing table of the kernel protocol stack via system calls or kernel-provided interfaces. When it detects a target route entry in the kernel routing table, it extracts these entries and synchronizes them to the forwarding table of the user-space network protocol stack, ensuring consistency between the forwarding table and the kernel routing table. The target route entry is recalculated and reissued to the kernel routing table by the routing control plane when the link state changes. Link state changes can include network interface disconnection, restoration, and bandwidth changes. These changes can be determined by the routing control plane after parsing and processing routing control messages received from external routing control planes.

[0034] After obtaining the target routing entry, the user-space network protocol stack synchronizes the target routing entry to the forwarding table. The synchronization process may include adding new routing entries, updating existing entries, and deleting invalid entries, thereby maintaining the forwarding table.

[0035] In some possible implementations, the router plugin creates an interface network device with the same configuration as the host interface of the user-space network protocol stack. This interface network device connects the user-space network protocol stack and the router plugin. In other words, to establish a connection between the router plugin and the user-space network protocol stack, the router plugin creates an interface network device in the host operating system for the data plane and hard-connects it to the data plane device. This interface network device can act as a mirror of the virtual network interface card bound to the user-space network protocol stack, with the same configuration as the host interface of the user-space network protocol stack. The interface network device connects the user-space network protocol stack and the router plugin to transmit data or control information between the user-space network protocol and the kernel protocol stack. Through the configuration of the interface network device, the user-space network protocol stack can access the routing table of the kernel protocol stack through the router plugin. The consistency between the interface network device's configuration and the host interface of the user-space network protocol stack ensures seamless communication between the two.

[0036] Step 430: Transmit the target message based on the target forwarding table entry.

[0037] Step 440: Receive the second routing control message sent by the second container node through the virtual network interface card; the second container node is any container node in the container network environment.

[0038] Based on such Figure 1 The diagram illustrates the architecture of a container network environment. In this environment, each container node is connected to the OVS bridge via an OVS bridge. Each container node is connected to the OVS bridge via a virtual NIC. Furthermore, each container node can also connect to the OVS bridge via a virtual NIC, enabling routing control information exchange between the container nodes. Based on this, the first container node can receive a second routing control message sent by the second container node through its virtual NIC. This routing control message may contain link state (LS) messages, routing state maintenance messages, etc.

[0039] Step 450: The second routing control message is transmitted to the routing control plane through the kernel protocol stack so that the routing control plane can parse and process the second routing control message to obtain the parsing result.

[0040] When transmitting the second routing control message, the user-space network protocol stack can push the second routing control message to the kernel protocol stack through the router plugin, so that the kernel protocol stack can transmit the second routing control message to the routing control plane.

[0041] If the routing control plane detects a change in link state, it needs to recalculate the route and inject the routing information into the kernel routing table. After the user-space network protocol stack detects the update of the kernel routing table, it obtains the new routing information and updates its own forwarding table, so that in subsequent packet transmission, it forwards packets based on the updated forwarding table.

[0042] It should be noted that the process of the user-space protocol stack transmitting messages outwards and inwards can be performed synchronously or asynchronously, and this application does not impose any restrictions on this.

[0043] In summary, the message transmission method provided in this application configures a user-space network protocol stack in a container node within a container network environment, establishes a communication relationship between the user-space network protocol stack and the routing control plane through a kernel protocol stack, and establishes a mapping relationship between the host interface of the user-space network protocol stack and the forwarding interface of the container node. This allows the user-space protocol stack to receive target messages during message transmission, query the target forwarding table entry corresponding to the destination IP address of the target message in the forwarding table, and then transmit the target message based on the target forwarding table entry. The target message can be a traffic message received through a virtual network interface card (NIC) or a first routing control message sent by the routing control plane. This method utilizes the user-space network protocol stack to perform routing and forwarding functions, avoiding the performance bottleneck of the traditional kernel protocol stack that limits message transmission efficiency and improving message transmission efficiency. Furthermore, the user-space network protocol stack offers greater flexibility and performance advantages, thus enhancing the scalability of the container network environment.

[0044] Furthermore, through the interaction between the router plugin and the kernel protocol stack, the user-space network protocol stack can synchronize routing information in the kernel routing table in real time, ensuring the accuracy and consistency of the forwarding table, thereby further improving the reliability and efficiency of packet forwarding. By receiving and processing second routing control messages through a virtual network interface card, the user-space network protocol stack can respond promptly to changes in network topology and dynamically adjust routing policies, enhancing the adaptability and stability of the container network environment.

[0045] The message transmission method and container network environment construction provided in this application can be applied to space network simulation to simulate complex network environments, verify routing protocols, and evaluate the network behavior of containerized applications. This application provides a space network simulation platform containing multiple container nodes, each simulating a space network node. Each container node runs a user-space network protocol stack, a kernel protocol stack, and a routing control plane. The user-space network protocol stack and the routing control plane communicate through the kernel protocol stack. A mapping relationship is established between the host interface of the user-space network protocol stack and the forwarding interface of the container node. Each container node is based on... Figure 3 or Figure 4 The message transmission method provided in the illustrated embodiment is used for message transmission.

[0046] The platform architecture of the space network simulation platform can be referenced. Figure 1 The structure of the container network environment shown is illustrated. This spatial network simulation platform achieves dynamic topology of the container network environment by adding action flow tables to the virtual network interfaces corresponding to each container node. The action flow tables include forwarding flow tables and drop flow tables. Schematic, during the simulation, the OVS bridge forwards network traffic between containers according to its default flow table "actions=NORMAL". When there is only this flow table entry in the OVS bridge, all network traffic will use the default behavior, i.e., forwarding. When an "actions=drop" flow table (i.e., a forwarding flow table) is added to a specific port of the OVS bridge, the container node corresponding to that specific port can be disconnected to simulate the disconnection of the corresponding spatial network node. Afterwards, the link is restored by deleting the "actions=drop" flow table (i.e., a drop flow table) to simulate the restoration of the connection of the corresponding spatial network node.

[0047] In illustrative terms, the space network simulation platform can use the message transmission method and container network environment construction method provided in the embodiments of this application to simulate complex network topologies, such as data center networks, cloud computing environments, edge computing networks, and low Earth orbit satellite network scenarios, etc.

[0048] Taking the Iridium LEO network scenario built on the space network environment using a space network simulation platform and conducting simulation experiments, with the routing control plane in the container node being the Quagga process and the user-space network protocol stack being the VPP process as an example, this process can be implemented as follows: Deploy several soft-router container nodes in the simulation server.

[0049] By connecting each container node to the forwarding plane OVS bridge "ovsbr0" through virtual NIC pairs (i.e., veth pairs), the connection relationship between the container node and the OVS bridge conforms to the Iridium satellite scenario.

[0050] A network application runs on each container node: This network application is used to deploy the track parameters, network configurations, and other information of each soft router container node in the file system of each container node in the form of configuration files; based on the information in the configuration files, the ospfd (Open Shortest Path First Daemon) daemon, zebra daemon, VPP process, and other network applications (such as dynamic topology implementation and link characteristic control) of the routing Quagga process are started synchronously; among them, the ospfd daemon is responsible for running the OSPF (Open Shortest Path First) dynamic routing protocol, the zebra daemon is responsible for communication between the kernel and the ospfd process, and the VPP process is responsible for providing data plane support for the soft router container.

[0051] To establish communication between the Quagga process and the VPP process, a router plugin is provided in the VPP process's sandbox. This plugin creates an interface network device (i.e., a Tap interface) for each data plane device in the host operating system and hard-connects it to the data plane device. This Tap interface, as a mirror of the veth bound to the VPP, needs to be configured to be completely consistent with the host interface corresponding to the VPP process. This allows Quagga routing packets (i.e., second routing packets) received by the VPP to enter the kernel protocol stack through the Tap interface and ultimately be delivered to the Quagga process's daemon, realizing data transmission from the VPP process to the Quagga process. At the same time, this plugin implements a Netlink-based communication mechanism, enabling the VPP process to synchronously maintain its own forwarding table based on the routing information sent to the kernel routing table by the Quagga process.

[0052] In the spatial network simulation platform, each logical network of each container node corresponds to two virtual network devices in the kernel space: veth, which establishes connections between containers, and Tap interface, which is configured with host interfaces in the VPP process. veth is used to directly send received packets to the VPP process, while Tap interface is responsible for delivering routing control packets passed by the VPP process to the Quagga process.

[0053] After route convergence and network connectivity is stable, packet capture tools are used to capture the two virtual network devices. Both the Tap interface and veth will receive routing control messages from the Quagga process for route state maintenance. In other words, routing-related messages are first sent to the VPP process via veth, and then the VPP process sends them to the Quagga process via the Tap interface for parsing and processing.

[0054] To verify network performance, iperf can be used to generate traffic between any two container nodes, and packet capture can be performed on two virtual network devices of a VPP process along the path. In this case, only veth receives packets from the client iperf process, while the Tap interface only receives routing control messages from the Quagga process. Illustratively, the iperf packets received by the virtual network interface can display TCP communication information between two IP addresses. In the forwarding table of this VPP process, the forwarding entry for the destination IP address can be found; that is, after receiving the traffic packets delivered by veth, the VPP process directly forwards the packets according to its own forwarding table content.

[0055] In the Iridium satellite scenario, when a satellite node enters the polar region, the relative speed between satellites in different orbits is too high, causing the satellite antenna to be unable to adjust and align in time, resulting in a temporary failure of the inter-satellite links in the polar region. When a satellite leaves the polar region, the link needs to be re-established, or other external factors may cause changes in the link status, all of which directly alter the topology of the satellite network, necessitating the re-establishment of inter-satellite routing relationships. During the simulation initialization phase, inter-satellite visibility relationships are imported into a local database. After the simulation begins, a custom daemon process runs in the container node. This process periodically accesses the inter-satellite visibility table stored in the local database according to the actual simulation timeline, adding "action=drop" flow tables to specific veth interfaces of satellites entering the polar region, or deleting "drop" flow tables when satellites leave the polar region, thereby simulating link interruption and recovery. After the aforementioned "link status" events occur, the Quagga process will be aware of them and begin a new round of routing calculations based on the current topology.

[0056] Taking a satellite about to enter a polar region as an example, when its link is lost upon entering the polar region, veth will receive LS Update (Link State Update) and LS ACK (Link State Acknowledgment) messages to update routing information. In other words, the routing control messages include LS Update and LS ACK messages, where the LS ACK message can be a "Hello" message. Subsequently, the VPP process will send these routing control messages to the Quagga process via the Tap interface for route calculation. After a certain period of route reconvergence, the link relationships return to stability. At this point, checking the routing table in the soft router container kernel will yield the routing table entries under the new topology. Simultaneously, the forwarding table entries in the VPP process will find information corresponding one-to-one with the kernel routing entries. When tracing routes between two adjacent satellites in different orbits entering the polar region, under the new network topology, traffic changes from being able to reach the destination directly in one hop to having to detour through non-polar nodes. To illustrate, the network path from the source host to the target host may change from one hop to three hops under the new network topology, thus adapting to the communication conditions in the polar environment.

[0057] Figure 5 This diagram illustrates a structural block diagram of a computer device 500 according to an exemplary embodiment of this application. This computer device can be implemented as a container node in the above-described scheme of this application. The computer device 500 includes a Central Processing Unit (CPU) 501, a system memory 504 including Random Access Memory (RAM) 502 and Read-Only Memory (ROM) 503, and a system bus 505 connecting the system memory 508 and the CPU 501. The computer device 500 also includes a mass storage device 506 for storing an operating system 509, a client 510, and other program modules 511. The system memory 504 and the mass storage device 506 can be collectively referred to as memory.

[0058] According to various embodiments of this application, the computer device 500 can also be connected to a remote computer on a network, such as the Internet. That is, the computer device 500 can be connected to a network 508 via a network interface unit 507 connected to the system bus 505, or the network interface unit 507 can be used to connect to other types of networks or remote computer systems (not shown).

[0059] The memory further includes at least one instruction, at least one program, code set, or instruction set, which are stored in the memory. The central processing unit 501 executes the at least one instruction, at least one program, code set, or instruction set to implement all or part of the steps in the message transmission method shown in the above embodiments.

[0060] In one exemplary embodiment, a computer-readable storage medium is also provided, which stores at least one computer program that is loaded and executed by a processor to implement all or part of the steps in the above-described message transmission method. For example, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, or optical data storage device, etc.

[0061] In one exemplary embodiment, a computer program product is also provided, the computer program product including a computer program stored on a non-transitory computer-readable storage medium, the computer program including program instructions that, when executed by a computer, cause the computer to perform the above-described actions. Figure 3 or Figure 4 All or part of the steps of the embodiments shown in any of the embodiments.

[0062] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0063] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A message transmission method, characterized in that, The method is executed by a user-space network protocol stack in a first container node. The first container node is any container node in a container network environment. The container node runs a user-space network protocol stack, a kernel protocol stack, and a routing control plane. The user-space network protocol stack and the routing control plane communicate through the kernel protocol stack. A mapping relationship is established between the host interface of the user-space network protocol stack and the forwarding interface of the container node. The method includes: Receive target message; the target message is a traffic message received through a virtual network interface card, or a first routing control message sent by the routing control plane; Search the forwarding table for the target forwarding entry corresponding to the destination IP address of the target packet; The target message is transmitted based on the target forwarding table entry.

2. The method according to claim 1, characterized in that, In the container network environment, each container node is connected to the OVS bridge via an open-source virtual switch; each container node is connected to the OVS bridge via a virtual network interface card (NIC), and the method further includes: The virtual network interface card (NIC) receives a second routing control message sent by a second container node; the second container node is any container node in the container network environment. The second routing control message is transmitted to the routing control plane through the kernel protocol stack, so that the routing control plane can parse and process the second routing control message to obtain the parsing result.

3. The method according to claim 2, characterized in that, The user-space network protocol stack is loaded with a router plugin, and the method further includes: Detect the kernel routing table of the kernel protocol stack; If the kernel routing table contains a target route entry, the target route entry is obtained through the router plugin; the target route entry is a route entry that is recalculated by the routing control plane when the link state changes and then sent to the kernel routing table. The forwarding table is maintained based on the target routing entry.

4. The method according to claim 3, characterized in that, The step of transmitting the second routing control message to the routing control plane through the kernel protocol stack includes: The second routing control message is pushed to the kernel protocol stack through the router plugin, so that the kernel protocol stack transmits the second routing control message to the routing control plane.

5. The method according to claim 4, characterized in that, The router plugin creates an interface network device, which has the same configuration as the host interface of the user-space network protocol stack; the interface network device is used to connect the user-space network protocol stack and the router plugin.

6. A space network simulation platform, characterized in that, The space network simulation platform includes multiple container nodes, each container node is used to simulate a space network node. Each container node runs a user-space network protocol stack, a kernel protocol stack, and a routing control plane. The user-space network protocol stack and the routing control plane establish a communication relationship through the kernel protocol stack. A mapping relationship is established between the host interface of the user-space network protocol stack and the forwarding interface of the container node. Each container node performs packet transmission based on the packet transmission method described in any one of claims 1 to 5.

7. The space network simulation platform according to claim 6, characterized in that, The spatial network simulation platform realizes the dynamic topology of the container network environment by adding action flow tables to the virtual network cards corresponding to each container node; the action flow tables include forwarding flow tables and drop flow tables.

8. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing at least one computer program, which is loaded and executed by the processor to implement the message transmission method as described in any one of claims 1 to 5.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one computer program, which is loaded and executed by a processor to implement the message transmission method as described in any one of claims 1 to 5.

10. A computer program product, characterized in that, The computer program product includes a computer program stored on a non-transitory computer-readable storage medium, the computer program including program instructions that, when executed by a computer, cause the computer to perform the message transmission method as described in any one of claims 1 to 5.

Images