CN116939053A

CN116939053A - Inter-container communication method across hosts and network equipment

Info

Publication number: CN116939053A
Application number: CN202210318691.4A
Authority: CN
Inventors: 李雨晴; 陈果; 陈力; 林福生; 周桂华; 许婷婷
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2022-03-29
Filing date: 2022-03-29
Publication date: 2023-10-24

Abstract

The embodiment of the application discloses a method for inter-container communication across hosts and network equipment, wherein in the method, a server side can establish TCP connection with a client side through a port (namely a first preset port) specially used for establishing connection related to a container in the server side so as to obtain a host socket of the TCP connection, and the file descriptor of the host socket can be transmitted to the first container through address information of the first container received from the client side. Because the process does not need to transmit port information of the host to the client through the overlay network, and does not need to transmit file descriptors of host sockets to the container in the server through the overlay network, the overlay network does not need to be established before establishing TCP connection between the hosts, and therefore, the efficiency of establishing TCP connection can be improved, so that the container in the server and the container in the client can communicate in a short time through the file descriptors of the host sockets.

Description

Inter-container communication method across hosts and network equipment

Technical Field

The embodiment of the application relates to the field of data communication, in particular to a method for inter-container communication across hosts and network equipment.

Background

A Container (Container) is an executable unit of software in Container technology that is capable of encapsulating the code of an application with associated configuration files, libraries, and dependencies required to run the application, and can be moved and run on any operating system in any environment, which enables developers to seamlessly deploy the application across the environment. In general, a large number of containers are typically used to host portions of the application's logic, often requiring efficient and flexible communication between containers located on multiple hosts in a data center in order for the aforementioned portions to cooperatively serve certain tasks as a whole. Currently, there are four main modes of inter-container communication: bridge (bridge) mode, host (host) mode, macvlan (macvlan) mode, and overlay (overlay) mode. The overlay mode can more flexibly solve the problem of communication and isolation of containers across hosts, and is a main method for communication across host containers.

As shown in fig. 1A, in the overlay mode, when an application in a container transmits a packet, the packet needs to traverse an overlay network (overlay network) stack to add a network header (e.g., a virtual IP header and a virtual ethernet header), then a virtual switch adds a physical header (e.g., a user datagram protocol (user datagram protocol, UDP) header, a physical IP header, a physical ethernet header, etc. are added in an ethernet frame), and then the packet enters the host network stack to be transmitted through a physical network interface. Therefore, the conventional overlay mode inter-container communication scheme across hosts needs to perform 2 times of protocol stack encapsulation (i.e. perform one encapsulation when traversing the overlay network stack and perform one encapsulation when reaching the virtual switch) in the data packet transmission process, which results in low network data transmission efficiency and affects the application performance.

In this regard, researchers have proposed a scheme of inter-container communication across hosts that uses a distributed mechanism to discover services. Specifically, as shown in fig. 1B, when two containers located in different hosts need to communicate, a standard container coverage network is established between the two hosts, and the client host and the server host can communicate through the coverage network socket. Thus, the client host can acquire the IP address and port number of the server host through the container coverage network, and the server host can acquire the IP address and port number of the client host through the container coverage network. Then, the client host establishes a transmission control protocol (transmission control protocol, TCP) connection between the hosts through the obtained IP address and port number of the server host and the IP address and port number of the client host, and returns file descriptors of host sockets to the container of the server and the container of the client respectively, so that the containers at the two ends adopt the file descriptors of the host sockets to replace the file descriptors of the overlay network sockets for communication. Thus, the packets sent by the containers in the hosts at the two ends can bypass the protocol stack encapsulation (i.e. the encapsulation of the overlay network stack and the encapsulation of the virtual switch) inside the container, i.e. only 1 host network stack encapsulation is required, thus reducing the overhead of each packet conversion.

However, in the foregoing solution, before the hosts at both ends establish the TCP connection between the hosts, a standard container coverage network needs to be established in the background, and the port information of the hosts at the opposite end needs to be obtained depending on the standard container coverage network. Furthermore, after the TCP connection is established, it is also necessary that the containers at both ends communicate through the file descriptor of the host socket after replacing the file descriptor of the overlay network socket with the file descriptor of the host socket. Thus, the foregoing solution may result in a long connection establishment time, which may affect the performance of some applications that need to establish a connection quickly.

Disclosure of Invention

The application provides a method for inter-container communication across hosts and network equipment, which are used for improving the efficiency of establishing TCP connection between a server host and a client host, so that a container in the server and a container in the client can communicate in a short time through file descriptors of host sockets.

In a first aspect, the present application provides a method for inter-container communication across hosts, the method involving a client and a server. In the method, a server waits for a connection establishment request from a client at a first preset port, and when the server receives the connection establishment request from the client, the server and the client establish a TCP connection between the client and the server based on a host Internet Protocol (IP) address and a first preset port number of the server through a TCP three-way handshake process to obtain a host socket of the TCP connection. The host socket is used for communicating between the client host and the server host, the first preset port number is used for establishing connection related to a container in the server, and the container in the server comprises a first container. The server then receives information of the first container from the client over the TCP connection, the information of the first container being used to indicate a container in cross-host communication with a second container in the client. Then, the server transmits the file descriptor of the host socket to the first container based on the information of the first container, and the second container communicates with the first container based on the file descriptor.

In the present application, the server can establish a TCP connection with the client through a port (i.e., a first preset port) specially used for establishing a connection related to a container in the server to obtain a host socket of the TCP connection, and can also transmit a file descriptor of the aforementioned host socket to the first container through address information of the first container received from the client. Because the process does not need to transmit port information of the hosts to the client through the overlay network, and does not need to transmit file descriptors of host sockets to the containers in the server through the overlay network, the overlay network does not need to be pre-established before establishing TCP connections between the hosts, and therefore the efficiency of establishing TCP connections between the hosts in the server and the hosts in the client is improved, so that the containers in the server and the containers in the client can communicate in a short time through the file descriptors of the host sockets.

In a possible embodiment, the information of the first container includes address information of the first container, the address information of the first container being used to indicate a network domain address of the first container.

In this embodiment, it is proposed that when there is only one application process in the first container, the client only needs to notify the server of the address information of the first container, so that the server accurately transmits the file descriptor of the host socket to the first container based on the address of the first container. The method is beneficial to improving the accuracy of the file descriptor of the host socket returned to the first container by the server.

In a possible embodiment, the first container comprises at least two application processes, and the information of the first container further comprises an application identifier of the first application process. Optionally, the application indicated by the application identifier of the first application process is the same as the application indicated by the application identifier of the second application process in the second container.

In this embodiment, it is proposed that when there are at least two application processes in the first container, the client needs to notify not only the address information of the first container to the server, but also an application identifier of the first application process to the server, so that the server accurately transmits the file descriptor of the host socket to the first application process in the first container based on the address of the first container. The method is beneficial to improving the accuracy of the file descriptor of the host socket returned to the first container by the server.

In one possible implementation manner, the server stores a first correspondence, where the first correspondence includes a correspondence between address information of the first container and a first local socket, and the first local socket is used to indicate a first application process in the first container.

In one possible implementation manner, the server stores a first correspondence, where the first correspondence includes a correspondence between address information of the first container and at least two local sockets, each local socket in the at least two local sockets corresponds to an application identifier, and different application identifiers correspond to different local sockets in the first correspondence.

In one possible implementation manner, the server transmits the file descriptor of the host socket to the first container based on the information of the first container, including: the server determines the first local socket based on at least one of address information of the first container and application identification of the first application process and the first corresponding relation; the server transmits the file descriptor of the host socket to the first container based on the first local socket, so that the first application process in the first container communicates with the second application process in the second container through the file descriptor of the host socket.

In this embodiment, the server transmits the file description service of the host socket to the first container through the first local socket, instead of transmitting the file description service of the host socket to the first container through the overlay network. Therefore, the overlay network does not need to be established in advance before the TCP connection between the hosts is established, so that the efficiency of establishing the TCP connection between the server host and the client host is improved, and the container in the server and the container in the client can communicate through the file descriptor of the host socket in a short time.

In one possible implementation, the server includes a first container management module and a first routing module; the first local socket includes a first index for indicating the first application process and a second index for indicating the first routing module. Specifically, before the server determines the first local socket based on the address information of the first container and the first correspondence, the method further includes: the first routing module receives a registration message from the first container management module, the registration message including address information of the first container and the first index; the first routing module generates a second index based on the address information of the first container and the first index; the first routing module determining the first local socket based on the first index and the second index; the first routing module generates the first correspondence based on address information of the first container and the first local socket.

In this embodiment, it is proposed that when a first application process in a first container runs, the first container management module registers the application process with the first routing module, so that the first routing module generates a second index based on address information of the first container and a first index from the first container management module, and further generates a first local socket composed of the first index and the second index. The method is beneficial to improving the efficiency of generating the local socket.

In one possible embodiment, the address information of the first container includes an IP address of the first container and a port number of the first container.

In a second aspect, the present application provides a method for inter-container communication across hosts, the method involving a client and a server. In the method, when a second container in the client needs to communicate with a first container in the server, the client determines an IP address of a server host where the first container is located based on information of the first container. Then, the client establishes a TCP connection between the client and the server through the IP address of the server host and a first preset port number, so as to obtain a host socket of the TCP connection, wherein the host socket is used for the communication between the client host and the server host, and the first preset port number is used for establishing a connection related to a container in the server. Then, the client sends information of the first container to the server through the TCP connection, the information of the first container being used to indicate a destination address of a second container in the client for cross-host communication, the information of the first container being used to transmit a file descriptor of the host socket to the first container. At the same time, the client transmits a file descriptor of the host socket to the second container, which communicates with the first container based on the file descriptor.

In this embodiment, the client can establish a TCP connection with the server through a port (i.e., a first preset port) specially used for establishing a connection related to a container in the server, so as to obtain a host socket of the TCP connection, and can also transmit address information of the first container to the server through the TCP connection, so that the server can transmit a file descriptor of the host socket to the first container based on the address information of the first container. Because the process does not need the server to transmit port information of the host to the client through the overlay network, and does not need to transmit file descriptors of host sockets to the containers in the server through the overlay network, the overlay network is not required to be pre-established before the TCP connection between the hosts is established, and therefore the efficiency of establishing the TCP connection between the hosts of the server and the hosts of the client is improved, so that the containers in the server and the containers in the client can communicate in a short time through the file descriptors of the host sockets.

In a possible embodiment, the first container comprises at least two application processes, and the information of the first container further comprises an application identifier of the first application process.

It should be noted that, in the embodiment of the present application, there are various other embodiments, and specific reference may be made to the specific embodiment of the first aspect and the beneficial effects thereof, which are not described herein.

In a third aspect, the present application provides a network device, which serves as a server. The network device includes a first routing module, a first container management module, and a first kernel module.

The first routing module is configured to receive a TCP connection establishment request from a client at a first preset port. The first kernel module is used for establishing a Transmission Control Protocol (TCP) connection between the client and the server through the host Internet Protocol (IP) address of the server and a first preset port number, and returning a host socket of the TCP connection to the first routing module. The host socket is used for communicating between the client host and the server host, the first preset port number is used for establishing connection related to a container in the server, and the container in the server comprises a first container. In addition, the first routing module is further configured to receive information of the first container from the client over the TCP connection, the information of the first container being used to indicate a container in cross-host communication with a second container in the client. The first routing module is further configured to transmit a file descriptor of the host socket to a first container management module that manages the first container based on the information of the first container, and the second container communicates with the first container based on the file descriptor.

In one possible implementation, the first routing module is specifically configured to:

determining the first local socket based on at least one of address information of the first container and an application identifier of the first application process, and the first correspondence;

Transmitting the file descriptor of the host socket to a first container management module that manages the first container based on the first local socket, such that the first application process in the first container communicates with a second application process in the second container via the file descriptor of the host socket.

In one possible implementation, the first local socket includes a first index for indicating the first application process and a second index for indicating the first routing module.

At this time, the first routing module receives a registration message from the first container management module, the registration message including address information of the first container and the first index; the first routing module generates a second index based on the address information of the first container and the first index; the first routing module determining the first local socket based on the first index and the second index; the first routing module generates the first correspondence based on address information of the first container and the first local socket.

In a fourth aspect, the present application provides a network device, which acts as a client. The network device includes a second routing module, a second container management module, and a second kernel module.

The second routing module is configured to determine, based on information of the first container, an IP address of a server host where the first container is located. The second kernel module is configured to establish a TCP connection between the client and the server through the IP address of the server host and the first preset port number, and return a host socket of the TCP connection to the second routing module. The host socket is used for communicating between the client host and the server host, and the first preset port number is used for establishing connection related to a container in the server. The second routing module is further configured to send, to the server, information of the first container through the TCP connection, where the information of the first container is used to indicate a destination address of a second container in the client for cross-host communication, and the information of the first container is used to transmit a file descriptor of the host socket to the first container. The second routing module is further configured to transmit a file descriptor of the host socket to a second container management module that manages the second container, such that the second container communicates with the first container based on the file descriptor.

In one possible implementation, the second container management module sends the information of the first container to the second routing module.

In a fifth aspect, the present application provides a network device comprising a processor and a memory; wherein the memory stores a computer program; the processor invokes the computer program to cause the network device to perform the method of the first aspect, the second aspect and any implementation of the preceding aspects.

In a sixth aspect, an embodiment of the present application provides a network device, where the network device may be a computer or a server, and may also be a chip in the computer or the server or a chip in a router. The network device may include a processing module and a transceiver module. When the network device is a computer or a server, the processing module may be a processor and the transceiver module may be a transceiver; the server or computer may also include a storage module, which may be a memory; the storage module is configured to store instructions, and the processing module executes the instructions stored by the storage module to cause the server or computer to perform the method of the first aspect, the second aspect, and any implementation of the foregoing aspects. When the network device is a computer or a chip in a server, the processing module may be a processor, and the transceiver module may be an input/output interface, a pin, a circuit, or the like; the processing module executes instructions stored by the storage module to cause the server or computer to perform the first aspect, the second aspect, and the methods of any of the foregoing aspects of any implementation. The memory module may be a memory module (e.g., register, cache, etc.) within the chip, or a memory module (e.g., read only memory, random access memory, etc.) within the server or computer that is external to the chip.

In a seventh aspect, the application provides a computer program product comprising instructions which, when run on a computer, cause the computer to perform the method as described in the first aspect, the second aspect and any of the various embodiments of the various aspects described above.

In an eighth aspect, embodiments of the present application provide a computer readable storage medium comprising instructions which, when run on a computer, cause the computer to perform a method as described in the foregoing first aspect, second aspect, and any of the various embodiments of the foregoing aspects.

From the above technical solutions, the embodiment of the present application has the following advantages:

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the description below are only some embodiments of the present application.

FIG. 1A is an exemplary diagram of inter-container communication across a host over an overlay network in accordance with the prior art;

FIG. 1B is another exemplary diagram of inter-container communication across a host over an overlay network in accordance with the prior art;

FIG. 2 is a flow chart of a method of inter-container communication across hosts in accordance with the present application;

FIG. 3A is a schematic diagram of one embodiment of a network device involved in a method of inter-container communication across hosts in accordance with the present application;

FIG. 3B is a schematic diagram of one embodiment of a method of inter-container communication across hosts in accordance with the present application;

FIG. 4A is a diagram illustrating an example of a conventional TCP connection established via a socket;

FIG. 4B is a schematic diagram of another embodiment of a method of inter-container communication across hosts in accordance with the present application;

FIG. 5 is a schematic diagram of another embodiment of a network device involved in a method of inter-container communication across hosts in accordance with the present application;

FIG. 6 is a schematic diagram of another embodiment of a network device involved in a method of inter-container communication across hosts in accordance with the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present application, but not all embodiments.

The terms "first," "second," "third," "fourth" and the like in the description and in the claims and in the above drawings, if any, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments described herein may be implemented in other sequences than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

For ease of understanding, the following terms are first presented in relation to the present application:

Socket (socket): one way of cross-process communication (inter process communication, IPC) is an abstraction of endpoints that communicate between different application processes. The sockets may divide network domain sockets (internet domain socket) and Unix domain sockets (Unix domain socket) according to different communication domains. Wherein network domain sockets (also referred to as host sockets) are used to enable inter-process communication on different hosts. Typically, a network domain socket is represented by an IP address and a port number. For example, socket softfd=socket (IP address, port number), where "softfd" represents a file descriptor of the socket. Unix domain sockets (also known as IPC sockets) or native sockets) are used to enable inter-process communication on the same host. Generally, a Unix domain socket is a path of a socket type file in a file system.

File descriptor (fd): is an abstract concept for expressing references to documents. The file descriptor is in the form of a non-negative integer. In effect, the file descriptor is an index value that points to a record table of the open file for each process maintained by the kernel for that process. When the program opens an existing file or creates a new file, the kernel returns a file descriptor to the process. In Linux systems, everything is regarded as a file, when a process opens an existing file or creates a new file, the kernel returns a file descriptor to the process, where the file descriptor is an index created by the kernel for efficiently managing the opened file, and is used to point to the opened file, and all system calls for executing I/O operations pass through the file descriptor.

An overlay (overlay) network is a virtual logical network built on top of a physical network. overlay networks are commonly used to provide a useful abstraction over physical networks and to separate and protect different logical networks.

It should be understood that the inter-container communication method across hosts proposed by the present application is mainly applied to the scenario where containers located in different hosts communicate. For convenience of description, the host initiating the communication connection is referred to as a client host, and the host receiving the communication connection is referred to as a server host. Typically, the server host includes at least one container, each container including at least one application process. Similarly, the client host includes at least one container, each container including at least one application process. One application process in the client can communicate with the same application process in the server.

The main flow of the inter-container communication method across hosts provided by the present application will be described below with reference to fig. 2, in which, in this method, a server includes a first container, a client includes a second container, and the client and the server execute the following steps:

in step 201, the client determines, based on the address information of the first container, an IP address of a server host where the first container is located.

When a second container in the client needs to communicate with a first container in the server, the client can acquire address information of the first container. The address information of the first container is a destination address of the second container in the client for cross-host communication.

In one possible embodiment, the address information of the first container is network address information of the first container. Optionally, the address information of the first container includes an IP address of the first container and a port number of the first container.

Specifically, the client determines, based on the IP address of the first container, the IP address of the server host where the first container is located. Illustratively, the client obtains an IP address of a server host at which the first container is located based on the IP address management (IP address management, IPAM).

In addition, the client can also acquire a first preset port number preset manually. For example, the client obtains a first preset port number preset manually through a manual interactive interface, where the first preset port number is a port number preset by a user for establishing a connection related to a container in the server before the client establishes a connection with the server. Therefore, when a certain container in the client needs to communicate with a certain container in the server, the client can directly use the first preset port number to initiate a connection establishment request to the server. Specifically, refer to the description related to step 202.

In the conventional technology, after the client needs to establish the overlay network with the server, the client can obtain the IP address of the server and the port number of the server through the overlay network, so compared with the scheme of the conventional technology, the scheme of the application can save the time of establishing the overlay network equipment, and can enable the client to quickly obtain the IP address of the server and the port number of the server, thereby being beneficial to the client to quickly initiate a TCP connection establishment request to the server.

In step 202, the client establishes a TCP connection with the server based on the IP address of the server host and the first preset port number, and obtains a host socket of the TCP connection.

Specifically, the client can learn the IP address and the port number of the client host, and after obtaining the IP address and the first preset port number of the server host, the client initiates a TCP three-way handshake procedure to the server, and carries the IP address of the client host, the port number of the client host, the IP address and the first preset port number of the server host in the procedure. For example, the client sends a message 1 to the server, where the message 1 carries a Synchronization (SYN) field, a source port field of the message 1 carries a port number of the client host, and a destination port field of the message 1 carries a first preset port number. Meanwhile, the server waits for the message 1 at the first preset port number, and returns a message 2 to the client after receiving the message 1, where the message 2 carries a SYN field and an Acknowledgement (ACK) field, a source port field of the message 2 carries the first preset port number, and a destination port field of the message 2 carries a port number of the client host. Then, after the client receives the foregoing message 2, the client sends a message 3 to the server, where the message 3 carries an ACK field, a source port field of the message 3 carries a port number of the client host, and a destination port field of the message 1 carries a first preset port number. At this time, the TCP connection establishment between the client host and the server host is completed.

In addition, when the establishment of the TCP connection is completed, the client and the server can respectively obtain the host socket of the TCP connection. The host socket of the TCP connection consists of address information at both ends of the TCP connection. Specifically, the host socket is composed of an IP address of the client host, a port number of the client host, an IP address of the server host, and a first preset port number. The host socket may be expressed as "sockfd=socket (IP address of client host, port number of client host; IP address of server host, first preset port number)", for example. Where "sockfd" represents the file descriptor of the host socket.

After the client obtains the host socket for the TCP connection, the client will perform steps 203a and 203b, respectively.

In step 203a, the client sends information of the first container to the server.

Wherein the information of the first container comprises address information of the first container, the address information of the first container being used to indicate a network domain address of the first container.

Since the server can only determine, based on the first port number, that the host socket of the aforementioned TCP connection is for a certain container in the client to communicate with a certain container in the server, the server does not yet determine which container in the server the host socket is for cross-host communication. Therefore, the client needs to send the address information of the first container to the server, so that after the server receives the address information of the first container, the server transmits the file descriptor of the host socket to the first container based on the address information of the first container. Specifically, please refer to step 204.

Optionally, when the first container includes at least two application processes, the information of the first container includes an application identifier of the first application process in addition to the address information of the first container. At this time, the client needs to send the address information of the first container and the application identifier of the first application process to the server, so that after the server receives the address information of the first container and the application identifier of the first application process, the server transmits the file descriptor of the host socket to the first container based on the address information of the first container and the application identifier of the first application process, and then transmits the file descriptor to the first application process. Specifically, please refer to step 204.

In step 203b, the client transmits the file descriptor of the host socket to the second container.

Specifically, since the client can learn that the second container in the client needs to be in communication connection with the first container in the server, the client can transmit the file descriptor of the host socket to the second container after obtaining the host socket.

It should be understood that, in the present application, there is no explicit time sequence limitation between the step 203a and the step 203b, the client may perform the step 203a first and then perform the step 203b, the client may perform the step 203b first and then perform the step 203a, and the client may also perform the step 203a and the step 203b simultaneously, which is not limited herein specifically.

In step 204, the server transmits the file descriptor of the host socket to the first container based on the address information of the first container.

For example, if there is only one application process (e.g., a first application process) in the first container, the first correspondence may include only address information of the first container and a first local socket of the first application process, where the first local socket is used to indicate the first application process in the first container. At this time, the first correspondence relationship may be as shown in the following table 1-1:

TABLE 1-1

Address information of container	Local socket
		Address information of first container	First local socket

In this embodiment, the server determines the first local socket based on the address information of the first container and the first correspondence. Then, the server transmits the file descriptor of the host socket to the first container based on the first local socket, so that the first application process in the first container communicates with the second application process in the second container through the file descriptor of the host socket.

In another possible embodiment, the first correspondence includes a correspondence between address information of the first container and at least one local socket. Wherein each local socket is used for indicating one application process in the first container, and different local sockets correspond to different application processes in the first container.

Optionally, when the first container includes at least two application processes, the first correspondence relationship includes, in addition to the address information of the first container and the local socket corresponding to each of the at least two application processes, an application identifier of each of the at least two application processes. Wherein each of the application identifiers corresponds to one of the local sockets in the first correspondence, and different ones of the application identifiers correspond to different ones of the local sockets in the first correspondence.

For example, if the first container includes at least two application processes (for example, a first application process and a third application process), the first correspondence includes, in addition to address information of the first container, a first local socket of the first application process, and a third local socket of the third application process, an application identifier of the first application process and an application identifier of the third application process. At this time, the first correspondence relationship may be as shown in the following table 2-1:

TABLE 2-1

In this embodiment, the server determines the first local socket based on the address information of the first container, the application identifier of the first application process, and the first correspondence. Then, the server transmits the file descriptor of the host socket to the first container based on the first local socket, so that the first application process in the first container communicates with the second application process in the second container through the file descriptor of the host socket.

In step 205, the application in the second container communicates with the application process in the first container via the file descriptor of the host socket.

In this embodiment, after the first container transmits the file descriptor of the host socket to the first container and the second container transmits the file descriptor of the host socket to the second container, the second container in the client may communicate with the first container in the server based on the host socket.

Fig. 3A is a schematic structural diagram of a network device according to the present application. The client or the server in the foregoing method embodiment corresponding to fig. 2 may be based on the structure of the network device shown in fig. 3A in this embodiment.

As shown in fig. 3A, the network device includes a container management module, a routing module, and a kernel module.

The container management module is used for managing containers in the host. Alternatively, the container management module is a library that can be dynamically linked to the application processes in the container. At this time, the container management module can intercept socket-related system calls of the container application process, for example, function calls such as socket (), bind (), listen (), connect (), and the like. Specifically, the function of each function call will be described later with reference to fig. 4A. Wherein the container management module is for linking to the binary file of the application in the container. Alternatively, the container management module may use LD_PRELOAD to dynamically link to application binaries in the container.

And the routing module is used for assisting in establishing the TCP connection, maintaining the first corresponding relation and transmitting the host socket to the corresponding container. Alternatively, the routing module may be a user space process running in a host namespace (namespace).

The kernel module is used for establishing a TCP connection to generate a host socket of the TCP connection and tracking or revoking the host socket used in the container.

As shown in fig. 3B, taking an example that the server includes a first routing module and a first container management module for managing a first container, the client includes a second routing module and a second container management module for managing a second container.

When a second container in the client needs to communicate with a first container in the server, the second container management module in the client sends the IP address of the first container and the port number of the first container to the second routing module. After the second routing module receives the IP address of the first container and the port number of the first container, the second routing module determines the host IP address of the server where the first container is located based on the IP address of the first container. Then, the second routing module initiates a TCP connection establishment request to the server based on the host IP address and the first preset port number of the server, and at the same time, the first routing module in the server can wait for the TCP connection establishment request at the first preset port number. Thus, after the first routing module receives the aforementioned TCP connection establishment request, the second routing module and the first routing module will undergo a three-way handshake procedure to establish a TCP connection. When the TCP connection is established, the first routing module and the second routing module may both obtain the host socket of the TCP connection, and the specific description of the host socket may refer to the related description in the corresponding embodiment of fig. 2, which is not repeated herein.

After the second routing module obtains the host socket, the second routing module returns the file descriptor of the host socket to the second container management module to enable the second application process in the second container to communicate with the container that also has the host file descriptor through the host file descriptor.

It should be appreciated that when the server runs the first container, the first container management module registers information about the first container with the first routing module. Specifically, the first container management module will send a registration message to the first routing module, the registration message including address information of the first container and the first index. Optionally, the registration message further includes an application identifier of the first application process. The first routing module then generates a second index based on the address information of the first container and the first index, and the first routing module determines the first local socket based on the first index and the second index. Then, the first routing module generates the first correspondence based on the address information of the first container and the first local socket.

The second routing module will then send the IP address of the first container and the port number of the first container to the first routing module. The first routing module queries a first correspondence (for example, table 1-1 and table 2-1 described above) based on the IP address of the first container and the port number of the first container to obtain a first local socket corresponding to the first container, where the first local socket is used to implement local communication between the first routing module and the first container management module. The first local socket comprises a first index and a second index, the first index is used for indicating a first application process in the first container, and the second index is used for indicating the first routing module. The first routing module transmits a file descriptor of a host socket to a first container through a first local socket, so that a first application process in the first container can communicate with a second application process in a second container through the host file descriptor.

In this embodiment, the second routing module in the client may establish a TCP connection with the first routing module in the server through a first preset port (i.e. a port dedicated to establishing a connection related to the container in the server), so as to obtain a host socket of the TCP connection, and may further transmit address information of the first container to the first routing module in the server through the TCP connection, so that the first routing module in the server may determine a first local socket corresponding to the first container based on the address information of the first container, and further the first routing module may transmit a file descriptor of the host socket to the first container. Because the overlay network does not need to be pre-established before the TCP connection between the hosts is established, the efficiency of establishing the TCP connection between the server host and the client host is improved, so that the container in the server and the container in the client can communicate in a short time through the file descriptor of the host socket.

The foregoing inter-container communication method across hosts will be described in connection with specific examples. Before describing a specific example, a simple description is made of functions related to a TCP connection establishment procedure in the conventional technology with reference to fig. 4A:

(1) A socket function, which may be expressed as "sockfd=socket ()", is used to establish a socket for a certain process. If the establishment is successful, the file descriptor of the established socket, i.e. "sockfd", is returned. Alternatively, the protocol family (e.g., IPv4, IPv6, unix, etc.) and socket type (e.g., byte stream socket, datagram socket, or original socket) may be specified by socket functions.

(2) The bind function, which may be denoted as "bind (addr)", is used to assign an address to a socket. Where "sockfd" is the file descriptor of the socket to which the address is to be assigned and "addr" is the local address that needs to be assigned to the socket. It is also understood that a socket with a file descriptor of "sockfd" is bound to the local address "addr".

(3) The connect function may be expressed as "connect (soft d, addr)", and is used for actively connecting the client to the server. The "software" is a file descriptor of a socket to be connected in the client, and the "addr" is an address of a server to which the client wants to connect. When the client calls the connect function to inform the client kernel to initiate TCP connection establishment, the client kernel establishes the TCP connection with the server kernel through three-way handshake.

(4) A listen function, which may be denoted as "listen (sockfd, backlog)", is used to treat a socket with a file descriptor of "sockfd" as a socket for a passive listening connection (i.e. passively waiting for a connection by a client). Where "backlog" is the length of the connection queue. The listen function feeds back to the kernel the file descriptor (i.e. "sockfd") of the socket and the length of the connection queue that need to passively snoop the connection, to enable the kernel to accept TCP connections. It can be understood that the client notifies the kernel to establish a connection through a connect () function, and the server notifies the kernel to establish a connection through a listen () function.

(5) an accept function, which may be denoted as "sockfd' =accept (addr)", is used to fetch a completed connection from the connection queue head in the established connection (published state). The "softfd" inherits the address of the server (i.e. the IP address of the server and the port number of the server); "addr" is the address of the client (i.e., the IP address of the client and the port number of the client); "sockfd'" is the file descriptor of the new socket returned by the accept function. The client and the server may communicate over a TCP connection via the file descriptor "sockfd'".

(6) The send function, which may be denoted as "send (softfd)", is used to transfer data to a specified socket. Where "softfd" represents the file descriptor of the socket that transferred the data, i.e., the send function specifies transferring the data to the socket whose file descriptor is "softfd".

(7) The recv function, which may be denoted as "recv (sockfd)", is used to transfer data from a specified socket. Where "sockfd" represents the file descriptor of the socket that transferred the data, i.e. the recv function specifies that the data is received from the socket whose file descriptor is "sockfd".

The foregoing inter-container communication method across hosts is described below in connection with the specific example shown in FIG. 4B. Taking as an example that the container 2 in the client host needs to establish a connection with the container 1 in the server host. The server host comprises a container management module 1, a routing module 1 and a server kernel, and the client host comprises a container management module 2, a routing module 2 and a client kernel. In this example, the IP address of the server host is 1.2.3.4 and the port number is 1234, the IP address of the container 1 is 10.0.0.1 and the port number is 80, the IP address of the client host is 1.2.3.5 and the port number is 1111, and the IP address of the container 2 is 10.0.0.2 and the port number is 60.

First, for the server, when the application process 1 in the container 1 in the server is started, the container management module 1 in the server will call the function socket () to create a network domain socket with a file descriptor of "c_s" for the container 1 (i.e., a socket with a file descriptor of "c_s", hereinafter referred to as socket c_s), i.e., "c_s=socket ()". Then, the container management module 1 recalls the function bind () to bind the IP address and port number of the container 1 for the socket c_s, i.e. "bind (c_s, 10.0.0.1, 80)". At this time, the IP address corresponding to socket c_s is 10.0.0.1 and the port number is 80. In addition, the container management module 1 will also call function socket () to create an index of the local socket at the container end (i.e. the first index described in the embodiment corresponding to fig. 3B) (i.e. uds_container=8) for the application process 1 in the container 1, where "UDS" is a file descriptor of the local socket, and 8 represents the index of the local socket UDS at the container end. Then, the server kernel stores the first index and a process number (process IDs) of the application process 1 correspondingly, so that the container management module 1 can accurately find the application process 1 based on the first index.

Meanwhile, the routing module 1 in the service side calls the function socket () to create a network domain socket whose file descriptor is "h_s" (i.e., a socket whose file descriptor is "h_s", hereinafter referred to as socket h_s), i.e., "h_s=socket ()". Then, the routing module 1 recalls the function bind () to bind the IP address and port number of the server host for the socket h_s, i.e. "bind (h_s, 1.2.3.4, 1234)". At this time, the IP address corresponding to socket h_s is 1.2.3.4 and the port number is 1234.

The container management module 1 will then establish a connection between the application process 1 in the container 1 and the routing module 1 via a local socket, i.e. a Unix Domain Socket (UDS), to enable the container management module 1 to send a registration message to the routing module 1, the registration message comprising the IP address of the container 1, the port number of the container 1 and the aforementioned first index. Then, when the routing module 1 receives the foregoing registration message, the routing module 1 creates an index of the socket UDS at the routing end (i.e. a second index described in the embodiment corresponding to fig. 3B) based on the IP address of the container 1, the port number of the container 1 and the foregoing first index (i.e. uds_route=7), where 7 represents the index of the local socket UDS at the routing end. At this time, the routing module 1 obtains a local socket for the application process 1 in the container 1 to communicate with the routing module 1, i.e., uds=socket (7, 8), and the routing module 1 adds an entry in the socket mapping table maintained by the routing module 1, the entry packet including ip=10.0.0.1 of the container 1, port=80 of the container 1, uds_route=7, and uds_container=8. Similarly, when other application processes (e.g., application process 3 in container 3) are running in the server, container management module 1 will also generate the network domain socket of container 3 and the local socket index of application process 3 according to the steps described above, and register the network domain socket of container 3 and the local socket of application process 3 described above with routing module 1. Thus, the routing module 1 is able to distinguish between different containers and different applications based on the aforementioned socket mapping table.

In addition, after routing module 1 calls function bind (), the call function listen () is also turned to a socket that passively listens for connection requests, to enable routing module 1 to listen for connection requests from clients at an interface with IP address 1.2.3.4 and port 1234.

Meanwhile, for the client, when the application process 2 inside the container 2 in the client needs to communicate with the application processes in other containers (for example, the application process 1 in the foregoing container 1), the container management module 2 in the client will call the function socket () to create a network domain socket with a file descriptor of "c_con" for the container 2 (i.e., a socket with a file descriptor of "c_con", hereinafter referred to as "socket c_con"), i.e., "c_con=socket ()". In addition, the routing module 2 in the client will call the function socket () to create a network domain socket whose file descriptor is "h_con" (i.e., a socket whose file descriptor is "h_con", hereinafter referred to as socket h_con "), i.e.," h_con=socket () ".

When the container 2 wants to establish a connection with the container 1, the container management module 2 redirects the function connect (c_con, 10.0.0.1, 80) for establishing a TCP connection with the container 1 to the routing module 2, i.e. the container management module 2 will send the IP address of the container 1 (i.e. IP address 10.0.0.1) and the port number of the container 1 (i.e. port number 80) to the routing module 2. Where "c_con" indicates the file descriptor of the socket of the connection to be established between container 2 and container 1, "10.0.0.1, 80" is the destination address and destination port of the aforementioned connection, i.e. the IP address and port number of container 1. When the routing module 2 receives the IP address and port number of the foregoing container 1 from the container management module 2, the routing module 2 determines, through IPAM, that the IP address of the host where the container 1 with IP of 10.0.0.1 is located is 1.2.3.4, that is, the routing module 2 can determine the IP address of the server host based on the IP address of the container 1. In addition, the routing module 2 can also obtain a port number (i.e., a first preset port number) preset for the server host for inter-container communication, i.e., a first preset port number 1234. The routing module 2 then invokes a function connect (h_con, 1.2.3.4, 1234) to establish a TCP connection between the routing module 2 in the client and the routing module 1 in the server. Where "h_con" represents a file descriptor of a socket of a connection between the routing module 2 and the routing module 1 to be established, and "1.2.3.4, 1234" represents an IP address and a port number of the routing module 1. Since routing module 1 in the server has called function listen () to translate socket h_s into a socket that listens for connection requests from clients at the interface with IP address 1.2.3.4 and port 1234. Thus, when routing module 2 invokes function connect (h_con, 1.2.3.4, 1234), the client core will establish a TCP connection with the server core through a three-way handshake. After the TCP connection between routing module 2 and routing module 1 is established, routing module 1 invokes function h_con=accept (h_s, 1.2.3.5, 1111) to obtain a socket to establish the completed connection. Wherein, "h_s" inherits the address of the service end of the connection (i.e. the IP address of the routing module 1 and the port number of the routing module 1); "1.2.3.5, 1111" indicates the address of the client of the aforementioned connection (i.e., the IP address of routing module 2 and the port number of routing module 2); "h_con" is the file descriptor of the new socket returned by the accept function. At this time, the client (i.e., routing module 2) and the server (i.e., routing module 1) may communicate through the TCP connection via the file descriptor "h_con". The routing module 2 will then return the file descriptor (i.e. "h_con") of the socket of the TCP connection to the container 2 to enable the container 2 in the client to communicate with the server.

At this point, however, the routing module 1 does not perceive which container in the server the previously established TCP connection was intended to communicate with. Therefore, the routing module 2 needs to send the IP address and port number of the container 1 to the routing module 1 through the aforementioned TCP connection, so that the routing module 1 returns the file descriptor (i.e. "h_con") of the socket of the aforementioned TCP connection to the container 1. Since the IP address 10.0.0.1 and the port 80 are virtual network addresses of the container 1, the routing module 1 cannot transmit data to the container 1 based on only the IP address 10.0.0.1 and the port 80, and thus the routing module 1 finds that the local socket UDS corresponding to the container 1 having the IP address 10.0.0.1 and the port 80 is 8 at the container end based on the internally stored socket map table, and then the routing module 1 can accurately transmit the file descriptor (i.e. "h_con") of the socket of the TCP connection to the container 1 based on the uds_container=8, and the container management module 1 can determine that the information obtained from the uds_container=8 needs to be transmitted to the application process 1. To this end, the application process 1 in the client container 1 and the application process 2 in the server container 2 can communicate through the file descriptor "h_con".

In this embodiment, the client does not need additional communication to acquire port information of the server from the server during connection establishment, but performs TCP connection with the server by reserving a dedicated, pre-known host port (i.e., the first preset port), and then sends the IP address of the container 1 and the port number of the container 1 to the server through the TCP connection. Then, the routing module 1 in the server uses the socket mapping table to search the local socket index corresponding to the application process 1 of the container 1 locally, so that the routing module 1 transmits the file descriptor of the host socket to the container 1 through the local socket, and further the container 2 of the client and the container 1 of the server can communicate based on the file descriptor of the host socket. The process does not require that an overlay network be pre-established before the TCP connection between hosts is established, thus improving the efficiency of establishing TCP connections between the server host and the client host so that containers in the server and containers in the client can communicate over the file descriptors of the host sockets in a short time.

In addition, as shown in fig. 5, the present application further provides a network device 50, and fig. 5 is a schematic structural diagram of the network device 50 provided by the present application. The network device 50 may be a network device such as a computer or a server that supports a transmission protocol such as TCP. Both the server and the client in the foregoing method embodiments corresponding to fig. 2, 3B, or 4B may be based on the structure of the network device 50 shown in fig. 5 in this embodiment.

As shown in fig. 5, the network device 50 may include a processor 510, a memory 520, and a transceiver 530. Wherein the processor 510 is coupled to the memory 520, the processor 510 is coupled to the transceiver 530.

The transceiver 530 may be referred to as a transceiver unit, a transceiver device, or the like. Alternatively, the device for implementing the receiving function in the transceiver unit may be regarded as a receiving unit, and the device for implementing the transmitting function in the transceiver unit may be regarded as a transmitting unit, that is, the transceiver unit includes a receiving unit and a transmitting unit, where the receiving unit may also be referred to as a receiver, an input port, a receiving circuit, etc., and the transmitting unit may be referred to as a transmitter, or a transmitting circuit, etc. In the present application, the transceiver 530 may transmit and receive TCP messages, IP messages, and the like. For example, when the network device 50 performs a method of a server, the transceiver 530 can receive a TCP connection establishment request from a client at a first preset port; accordingly, when the network device 50 performs the method of the client, the transceiver 530 is capable of sending a TCP connection establishment request to the client at the first preset port. In addition, the transceiver 530 may also receive information of the first container. For example, when the network device 50 performs a method of a server, the transceiver 530 can receive information of a first container from a client through a TCP connection; accordingly, when the network device 50 performs the method of the client, the transceiver 530 can transmit the information of the first container to the server through the TCP connection. Refer to the related description in the foregoing embodiments.

The aforementioned processor 510 may be a central processing unit (central processing unit, CPU), application-specific integrated circuit (ASIC), programmable logic device (programmable logic device, PLD), or a combination thereof. The PLD may be a complex programmable logic device (complex programmable logic device, CPLD), a field-programmable gate array (field-programmable gate array, FPGA), general-purpose array logic (generic array logic, GAL), or any combination thereof. Processor 510 may refer to one processor or may include multiple processors, and is not limited in this regard.

In addition, the aforementioned memory 520 is mainly used for storing software programs and data. The memory 520 may be separate and coupled to the processor 510. Alternatively, the memory 520 may be integrated with the processor 510, such as within one or more chips. The memory 520 is capable of storing program codes for implementing the technical solutions of the embodiments of the present application, and is controlled by the processor 510 to execute, and various types of executed computer program codes can also be regarded as drivers of the processor 510. Memory 520 may include volatile memory (RAM), such as random-access memory (RAM); the memory may also include a nonvolatile memory (non-volatile memory), such as a read-only memory (ROM), a flash memory (flash memory), a hard disk (HDD) or a Solid State Drive (SSD); memory 520 may also include a combination of the above types of memory. The memory 520 may refer to one memory or may include a plurality of memories. The memory 520 is used for storing a first correspondence, which includes a correspondence between address information of the first container and a first local socket, and the first local socket is used for indicating a first application process in the first container. Optionally, the first correspondence includes a correspondence between address information of the first container and at least two local sockets, each local socket of the at least two local sockets corresponds to an application identifier, and different application identifiers correspond to different local sockets in the first correspondence.

In one implementation, memory 520 has stored therein computer readable instructions comprising a plurality of software modules, such as container management module 521, routing module 522, and kernel module 523. Optionally, a routing module (not shown) is also included. Processor 510, upon execution of the various software modules, may perform the corresponding operations as directed by the various software modules. In this embodiment, the operations performed by one software module actually refer to operations performed by the processor 510 according to instructions of the software module.

Illustratively, when the network device 50 is configured to implement the function of the server, the container management module 521 in the network device 50 is a first container management module, the routing module 522 is a first routing module, and the kernel module is a first kernel module. The main functions of the first container management module, the first routing module and the first kernel module are as follows:

The rest of the methods related to the service end in the corresponding embodiments of fig. 2, 3B or 4B will not be described herein.

Illustratively, when the network device 50 is configured to implement the client function, the container management module 521 in the network device 50 is a second container management module, the routing module 522 is a second routing module, and the kernel module is a second kernel module. The main functions of the second container management module, the second routing module and the second kernel module are as follows:

The remainder of the methods related to the client in the corresponding embodiments of fig. 2, 3B or 4B will not be described herein.

In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in a processor or by instructions in the form of software. The steps of a method disclosed in connection with the embodiments of the present application may be embodied directly in a hardware processor for execution, or in a combination of hardware and software modules in the processor for execution. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in a memory, and the processor reads the information in the memory and, in combination with its hardware, performs the steps of the above method. To avoid repetition, a detailed description is not provided herein. It should also be understood that the first, second, third, fourth and various numerical numbers referred to herein are merely descriptive convenience and are not intended to limit the scope of embodiments of the present application.

In addition, as shown in fig. 6, the application also provides a device 60, and fig. 6 is a schematic structural diagram of the device 60. Both the server and the client in the foregoing method embodiments corresponding to fig. 2, 3B, or 4B may be based on the structure of the device 60 shown in fig. 6 in this embodiment. Alternatively, the device 60 may be a computer, server, or the like that supports the TCP transport protocol.

As shown in fig. 6, the apparatus 60 includes: a main control board 610 and an interface board 620.

The main control board is also called a main processing unit (main processing unit, MPU) or a routing processing card (route processor card), and the main control board 610 is used for controlling and managing various components in the device 60, including routing computation, device management, device maintenance, and protocol processing functions. The main control board 610 includes: a central processor 611 and a memory 612. Further, stored in memory 612 are computer readable instructions that include a plurality of software modules, such as a container management module, a routing module, and a kernel module. Alternatively, when the device 60 performs the method of the server, the container management module may be a first container management module, the routing module may be a first routing module, and the kernel module may be a first kernel module. Alternatively, when the device 60 performs the client method, the container management module may be a second container management module, the routing module may be a second routing module, and the kernel module may be a second kernel module. It can be understood that the container management module, the routing module and the kernel module are all configured on the main control board. In addition, the memory 612 is similar to the memory 520 of the corresponding embodiment of fig. 5, and refer to the description of the memory 520.

The interface board 620 is also referred to as a line interface unit card (line processing unit, LPU), line card, or service board. The interface board 620 is used to provide various service interfaces and to implement forwarding of data packets. The service interfaces include, but are not limited to, ethernet interfaces, such as flexible ethernet service interfaces (flexible ethernet Clients, flexE Clients), POS (Packet over SONET/SDH) interfaces, etc. The interface board 620 includes: a central processor 621, a network processor 622, a forwarding table entry memory 623, and a physical interface card (ph 10sical interface card, PIC) 624.

The central processor 621 on the interface board 620 is used for controlling and managing the interface board 620 and communicating with the central processor 611 on the main control board 610.

The network processor 622 is configured to implement forwarding processing of the packet. The network processor 622 may be in the form of a forwarding chip. The forwarding chip may be a network processor (network processor, NP). In some embodiments, the forwarding chip may be implemented by an application-specific integrated circuit (ASIC) or a field programmable gate array (field programmable gate array, FPGA). Specifically, the network processor 622 is configured to forward the received packet based on the forwarding table stored in the forwarding table entry memory 623, and if the destination address of the packet is the address of the device 60, upload the packet to the CPU (e.g. the central processor 621) for processing; if the destination address of the message is not the address of the device 60, the next hop and the outbound interface corresponding to the destination address are found from the forwarding table according to the destination address, and the message is forwarded to the outbound interface corresponding to the destination address. The processing of the uplink message may include: processing a message input interface and searching a forwarding table; the processing of the downlink message may include: forwarding table lookup, etc. In some embodiments, the central processor may also perform the function of a forwarding chip, such as implementing software forwarding based on a general purpose CPU, so that no forwarding chip is needed in the interface board.

The physical interface card 624 is used to implement the docking function of the physical layer, from which the original traffic enters the interface board 620, and from which processed messages are sent out from the physical interface card 624. A physical interface card 624, also referred to as a daughter card, may be mounted on the interface board 620 and is responsible for converting the optical signals into messages and forwarding the messages to the network processor 622 for processing after a validity check. In some embodiments, the central processor may also perform the functions of the network processor 622, such as implementing software forwarding based on a general purpose CPU, so that the network processor 622 is not required in the physical interface card 624.

Optionally, the device 60 comprises a plurality of interface boards, e.g. the device 60 further comprises an interface board 630, the interface board 630 comprising: a central processor 631, a network processor 632, a forwarding table entry memory 633, and a physical interface card 634. The function and implementation of the components in interface board 630 are the same as or similar to interface board 620 and will not be described in detail herein.

Optionally, the device 60 further comprises a switching fabric 640. The switch fabric 640 may also be referred to as a switch fabric unit (switch fabric unit, SFU). In the case of a network device having multiple interface boards (e.g., interface board 620 and interface board 630), the switch fabric 640 is used to complete the data exchange between the interface boards. For example, interface board 620 and interface board 630 may communicate via switch fabric 640.

The main control board 610 and the interface board 620 are coupled. For example. The main control board 610, the interface board 620 and the interface board 630 are connected with the system back board through a system bus to realize intercommunication among the exchange network boards 640. In one possible implementation, an inter-process communication protocol (inter-process communication, IPC) channel is established between the main control board 610 and the interface board 620, and communication is performed between the main control board 610 and the interface board 620 through the IPC channel.

Logically, the device 60 comprises a control plane comprising a main control board 610 and a central processor 621, and a forwarding plane comprising various components performing forwarding, such as a forwarding table entry memory 623, a physical interface card 624, and a network processor 622. The control plane performs the functions of router, generating forwarding table, processing signaling and protocol messages, configuring and maintaining the status of the device, etc., and the control plane issues the generated forwarding table to the forwarding plane, where the network processor 622 forwards the message table look-up received by the physical interface card 624 based on the forwarding table issued by the control plane. The forwarding table issued by the control plane may be stored in forwarding table entry memory 623. In some embodiments, the control plane and the forwarding plane may be completely separate and not on the same device.

It should be noted that the main control board may have one or more blocks, and the main control board and the standby main control board may be included when there are multiple blocks. The interface boards may have one or more, the more data processing capabilities the network device is, the more interface boards are provided. The physical interface card on the interface board may also have one or more pieces. The switching network board may not be provided, or may be provided with one or more blocks, and load sharing redundancy backup can be jointly realized when the switching network board is provided with the plurality of blocks. Under the centralized forwarding architecture, the network device may not need to exchange network boards, and the interface board bears the processing function of the service data of the whole system. Under the distributed forwarding architecture, the network device may have at least one switching fabric, through which data exchange between multiple interface boards is implemented, providing high-capacity data exchange and processing capabilities. Therefore, the data access and processing power of the network devices of the distributed architecture is greater than that of the devices of the centralized architecture. Alternatively, the network device may be in the form of only one board card, i.e. there is no switching network board, the functions of the interface board and the main control board are integrated on the one board card, and the central processor on the interface board and the central processor on the main control board may be combined into one central processor on the one board card, so as to execute the functions after stacking the two, where the data exchange and processing capability of the device in this form are low (for example, network devices such as a low-end switch or a router). The specific architecture employed is not limited in any way herein, depending on the specific networking deployment scenario.

Furthermore, the present application provides a computer program product comprising one or more computer instructions. When loaded and executed on a computer, produces a flow or function in accordance with embodiments of the application, in whole or in part. For example, the server-side related method as described in fig. 2, 3B, or 4B is implemented. As another example, a client-side related method as in fig. 2, 3B, or 4B described above is implemented. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line (digital subscriber line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be stored by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a digital versatile disk (digital versatile disc, DVD)), or a semiconductor medium (e.g., a Solid State Disk (SSD)), or the like.

Furthermore, the present application provides a computer-readable storage medium storing a computer program to be executed by a processor to implement the server-side related method as in the foregoing fig. 2, 3B or 4B.

Furthermore, the present application provides a computer-readable storage medium storing a computer program to be executed by a processor to implement the client-side related method as in the previous fig. 2, 3B or 4B.

It should be understood that the term "and/or" is merely an association relationship describing the associated object, and means that three relationships may exist, for example, a and/or B may mean: a exists alone, A and B exist together, and B exists alone. In addition, the character "/" herein generally indicates that the front and rear associated objects are an "or" relationship.

It should be understood that, in various embodiments of the present application, the sequence numbers of the foregoing processes do not mean the order of execution, and the order of execution of the processes should be determined by the functions and internal logic thereof, and should not constitute any limitation on the implementation process of the embodiments of the present application.

It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, which are not repeated herein.

The above embodiments are only for illustrating the technical solution of the present application, and are not limiting; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method of inter-container communication across hosts, comprising:

the method comprises the steps that a server establishes a Transmission Control Protocol (TCP) connection between a client and the server through a host Internet Protocol (IP) address and a first preset port number of the server to obtain a host socket of the TCP connection, wherein the host socket is used for communication between the client host and the server host, the first preset port number is used for establishing connection related to a container in the server, and the container in the server comprises a first container;

the server receives information of the first container from the client through the TCP connection, wherein the information of the first container is used for indicating a container which is communicated with a second container in the client in a cross-host mode;

The server transmits the file descriptor of the host socket to the first container based on the information of the first container, and the second container communicates with the first container based on the file descriptor.

2. The method of claim 1, wherein the information of the first container comprises address information of the first container, the address information of the first container being used to indicate a network domain address of the first container.

3. The method of claim 2, wherein the first container includes at least two application processes, and wherein the information of the first container further includes an application identification of the first application process.

4. A method according to claim 2 or 3, wherein the server stores a first correspondence, the first correspondence comprising a correspondence between address information of the first container and a first local socket, the first local socket being used to indicate a first application process in the first container.

5. A method according to claim 3, wherein the server stores a first correspondence, the first correspondence including a correspondence between address information of the first container and at least two local sockets, each of the at least two local sockets corresponding to an application identifier, and different ones of the application identifiers corresponding to different ones of the first correspondences.

6. The method according to any one of claims 3 to 5, wherein the server transmitting the file descriptor of the host socket to the first container based on the information of the first container, comprises:

the server determines the first local socket based on at least one of address information of the first container and application identification of the first application process and the first corresponding relation;

the server transmits the file descriptor of the host socket to the first container based on the first local socket, so that the first application process in the first container communicates with the second application process in the second container through the file descriptor of the host socket.

7. The method of claim 6, wherein the server comprises a first container management module and a first routing module; the first local socket comprises a first index and a second index, the first index is used for indicating the first application process, and the second index is used for indicating the first routing module;

before the server determines the first local socket based on the address information of the first container and the first correspondence, the method further includes:

The first routing module receives a registration message from the first container management module, the registration message including address information of the first container and the first index;

the first routing module generates a second index based on the address information of the first container and the first index;

the first routing module determining the first local socket based on the first index and the second index;

the first routing module generates the first correspondence based on address information of the first container and the first local socket.

8. The method according to any one of claims 1 to 7, wherein the address information of the first container includes an IP address of the first container and a port number of the first container.

9. A method of inter-container communication across hosts, comprising:

the client determines the IP address of a server host where a first container is located based on the information of the first container;

the client establishes TCP connection between the client and the server through an IP address of the server host and a first preset port number, so as to obtain a host socket of the TCP connection, wherein the host socket is used for the communication between the client host and the server host, and the first preset port number is used for establishing connection related to a container in the server;

The client sends information of the first container to the server through the TCP connection, wherein the information of the first container is used for indicating a destination address of a second container in the client for cross-host communication, and the information of the first container is used for transmitting a file descriptor of the host socket to the first container;

the client transmits a file descriptor of the host socket to the second container, which communicates with the first container based on the file descriptor.

10. The method of claim 9, wherein the information of the first container includes address information of the first container, the address information of the first container being used to indicate a network domain address of the first container.

11. The method of claim 10, wherein the first container includes at least two application processes, and wherein the information of the first container further includes an application identification of the first application process.

12. The method according to any one of claims 9 to 11, wherein the address information of the first container includes an IP address of the first container and a port number of the first container.

13. A network device comprising a processor and a memory;

wherein the memory stores a computer program;

the processor invokes the computer program to cause the network device to perform the method of any of claims 1 to 8 as a server.

14. A network device comprising a processor and a memory;

wherein the memory stores a computer program;

the processor invokes the computer program to cause the network device to perform as a client the method of any of claims 9 to 12.

15. A communication system, comprising:

a server performing the method of any one of claims 1 to 8, and a client performing the method of any one of claims 9 to 12.

16. A computer readable storage medium storing instructions which, when run on a computer, cause the computer to perform the method of any one of claims 1 to 8; alternatively, the method of any one of claims 9 to 12 is performed.

17. A computer program product comprising instructions which, when run on a computer, cause the computer to perform the method of any of claims 1 to 8; alternatively, the method of any one of claims 9 to 12 is performed.