Cross-CPU distributed general proxy communication route self-discovery method

Abstract

The invention relates to a cross-CPU distributed general proxy communication route self-discovery method, and belongs to the technical field of network communication. According to the method, the management communication protocol among the agent programs under different CPUs is designed, so that automatic and dynamic routing construction is realized. After the whole system is started, agent programs of all CPUs can construct a route of the whole network within a plurality of times of management data exchange, and manual participation is not needed during the period; and when a part of nodes crashes, the occurrence of problems can be automatically detected, and other selectable routes (if the selectable routes exist) are switched to, so that the work of the whole system is not influenced.

Description

Technical Field

[0001] The invention belongs to the technical field of network communication, and in particular relates to a cross-CPU distributed general proxy communication routing self-discovery method. Background Art

[0002] In the fields of embedded devices and special equipment, a device often contains multiple CPUs, or processing nodes. These processing nodes may be single-chip microcomputers or chips, etc., with independent computing capabilities, independent software and hardware environments and operating systems, and are deployed in different locations in the device to perform different functions. At the same time, these processing nodes also need to communicate with each other to jointly complete the device functions.

[0003] By connecting these processing nodes with physical or logical links, a network for data communication between nodes can be obtained. Compared with traditional computer networks and the Internet, this network is smaller in scale and simpler in structure: the number of communication nodes ranges from a few to more than a dozen, and generally does not exceed dozens. However, it also has problems that traditional computer networks do not have: computer networks already have mature layered encapsulation protocol stacks that can be used. Generally, system designers do not need to solve the specific implementation details of communication by themselves. They only need to call the network protocol stack API provided by the operating system and use IP, TCP, UDP and other protocols to send and receive data. In this application field, different types of communication links or communication protocols may be required between communication nodes according to specific scenarios, such as serial communication, PCIe communication, character device communication, UDP communication running on a general network protocol stack, etc., and the communication environment is relatively complex. If the application program is allowed to call the corresponding communication API directly according to the link and protocol type used, the business processing code and the communication implementation code will be coupled together, which is very complicated to implement; at the same time, when the network topology or link situation changes, the code needs to be modified one by one according to the changes involved, and the flexibility and scalability are extremely low. If custom communication protocols are used in certain scenarios, the complexity will be further increased. Summary of the invention

[0004] 1. Technical issues to be resolved

[0005] The technical problems to be solved by the present invention are: 1. Providing a universal data routing solution for distributed proxy programs; 2. When a node or link in the network fails, the routing solution can detect this situation and respond in a timely manner; 3. It can provide support for situations such as ring network topologies, while avoiding problems such as broadcast storms; 4. It can minimize manual participation and respond in a timely manner when the network topology changes, and has good flexibility and robustness.

[0006] (II) Technical solution

[0007] In order to solve the above technical problems, the present invention provides a cross-CPU distributed general agent communication routing self-discovery method, in which, first, a network topology is determined, and a globally unique ID is assigned to each CPU and each link; the CPU ID is used to uniquely identify a communication node and the agent program running on it, and the application program fills in the CPU ID of the communication destination for use by the agent program during data transmission; the link ID is used to uniquely identify a link; information about the CPU ID, link ID, and link type is written into each communication node in the form of a configuration file, and when the agent program is started, the configuration file is read and related initialization work is performed; in addition, each agent program maintains a routing table, which contains routing information of all other nodes in the network; if the network contains N communication nodes, the length of the routing table maintained by each agent program is N-1; each routing table entry consists of five items (target CPU ID, next hop CPU ID, link ID, distance, time); the target CPU ID and link ID identify the link from which data sent to a certain destination should be sent; the next hop CPU ID identifies the CPU directly connected to the corresponding link ID number; distance indicates the distance between the current node and the destination, expressed as the number of nodes passed; time indicates the time when this routing table entry was last updated, which is used for timeout processing;

[0008] Secondly, establish the initial route: When the entire network is started, the agent program on each communication node first discovers the initial route, as follows:

[0009] a) Each agent sends a routing detection packet, also known as a heartbeat packet, to all links directly connected to it. The format is (source CPU ID, previous hop CPU ID, distance). In the original heartbeat packet sent by each node, the distance is set to 0;

[0010] B) when certain node receives the heartbeat packet from other nodes, first check whether this node already has corresponding project in the routing table according to the source CPU ID field in the heartbeat packet; If not, then directly use the data in this heartbeat packet, the data (source CPU ID, last hop CPU ID, distance) in the heartbeat packet are written into the routing table item (target CPU ID, next hop CPU ID, distance) corresponding to the current node, at the same time, fill in the link ID field in the routing table item according to the link ID received, and update the time in the routing table item; If it exists, then according to the time field and the timeout interval of regulation, judge whether the corresponding table item in the routing table has timed out;

[0011] c) if timeout, directly use the data in the heartbeat packet to update the routing table item; otherwise, according to the last hop CPU ID in the heartbeat packet and the next hop CPU ID field in the routing table item, determine whether the data of the current routing table item and this heartbeat packet are from the same direct source; The last hop CPU ID in the heartbeat packet is to identify its last node on the receiving routing path, and the next hop CPU ID in the routing table item is to identify its next node on the sending route, if these two IDs are identical, then represent that this heartbeat packet is sent by the same path as last time;

[0012] d) If the routing table entry and the heartbeat packet data come from the same source, and it is believed that the data in the heartbeat packet is actually the latest version of the data in the routing table entry, the data in the heartbeat packet is directly used to update the routing table entry, and the time in the routing table entry is refreshed at the same time;

[0013] If the routing table entry and the heartbeat packet data come from different sources, the heartbeat packet data is judged: compare the distance field in the heartbeat packet and the routing table. If the distance in the heartbeat packet is already greater than the distance recorded in the current routing table, it means that there is more than one path from this node to the target node, that is, there is a loop in this network, and this heartbeat packet is forwarded from a farther path, then the heartbeat packet is discarded; if there is no corresponding item in the routing table or the distance in the heartbeat packet is less than or equal to the distance recorded in the current routing table, it means that this heartbeat packet is valid and represents the latest data of the nearest route to the destination CPU ID. The current node updates the distance, link, next hop CPU ID and time fields of the routing table;

[0014] After the initial route is established, the agent program on each node also performs heartbeat detection at regular intervals and broadcasts heartbeat packets to indicate that the node it is in is working normally.

[0015] The present invention also provides a system for implementing the method.

[0016] (III) Beneficial effects

[0017] The present invention proposes a cross-CPU distributed general agent communication route self-discovery method, which realizes automatic and dynamic route construction by designing the management communication protocol between the agent programs under different CPUs. After the entire system is started, the agent programs of all the CPUs above can build the route of the entire network within several management data exchanges without manual participation; and when some nodes are down, they can automatically detect the occurrence of the problem and switch to other optional routes (if any) without affecting the work of the entire system. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 It is a general agent communication flow chart;

[0019] Figure 2 Create a flow chart for the initial routing. DETAILED DESCRIPTION

[0020] In order to make the purpose, content and advantages of the present invention more clear, the specific implementation methods of the present invention are further described in detail below in conjunction with the drawings and examples.

[0021] The present invention provides a cross-CPU distributed general proxy communication route self-discovery method. First, the following terms are explained:

[0022] Universal agent: an agent used to solve the problem of difficulty in communication and management between CPUs or communication nodes due to different channel types. After using the universal agent, when the application on each communication node wants to communicate with other communication nodes, it only needs to interact directly with the universal agent. The universal agent provides a unified communication API, shielding the specific channel type and communication processing details.

[0023] CPU: In the context of the present invention, it refers not only to the traditional CPU chip, but also to the module with independent computing and processing capabilities, relatively independent functions, and complete hardware and software environment in the fields of embedded and special equipment. The "processing node" and "communication node" in the following text have the same meaning as CPU in the context of this solution.

[0024] In order to solve these problems, the present invention introduces universal agent technology. A distributed universal agent program runs on each communication node, which is responsible for communicating with other communication nodes. The application only needs to send data to the agent of this node and specify the target for sending the data. The agent will handle all the communication details. The processing flows related to the link and protocol are all encapsulated inside the agent and can be flexibly configured in the form of configuration files. After receiving the data from the application, the agent program of this node selects the link, protocol, transit communication node (if necessary) and target communication node according to the topology of the network, and sends the data to the agent program running on the target communication node, which is finally forwarded to the target application by the agent program on the target communication node. The communication process is as follows: Figure 1When application 1-1 on CPU1 wants to send data to application 3-2 on CPU3, it first sends the data to agent 1. Agent 1 searches the local routing table according to the destination and finds that the data can be sent from link 1 to the destination. After selecting the link and protocol that match it, it sends the data from link 1 to agent 2 on CPU2. Agent 2 receives the data, determines that it needs to be forwarded, and performs the same operation. It sends the data from link 2 to agent 3 on CPU3 according to the destination, and finally agent 3 forwards it to application 3-2 on the same CPU.

[0025] In the above distributed general agent communication solution, there is another important problem to be solved: the application will only specify the destination CPU and destination application in the transmission, and for a specific data transmission, including the starting point, the agent program in each CPU on the data transmission path needs to know which link to send the data to, that is, the data routing problem between the agent-node network. The solution to the routing problem should be convenient and easy to use, and during the operation of the system, if a node or link fails, it can have a better handling method and be quite flexible and robust.

[0026] Therefore, the present invention proposes a cross-CPU distributed general agent communication route self-discovery method, which realizes automatic and dynamic route construction by designing the management communication protocol between the agent programs under different CPUs. After the entire system is started, the agent programs of all the CPUs above can build the route of the entire network within several management data exchanges without manual participation; and when some nodes are down, they can automatically detect the occurrence of problems and switch to other optional routes (if any) without affecting the work of the entire system.

[0027] 1. Solution design

[0028] In this routing method, you first need to draw a network topology diagram manually and assign a globally unique ID to each CPU and each link. The CPU ID is used to uniquely identify a communication node and the agent running on it. At the same time, the application needs to fill in the CPU ID of the communication destination for the agent to use during data transmission. The link ID is used to uniquely identify a link. In the subsequent routing table construction process, and when selecting the corresponding communication protocol, communication parameters, and communication API based on the link, the link information needs to be determined based on the link ID.

[0029] Information such as CPU ID, link ID, link type, etc. needs to be written into each communication node in the form of a configuration file. When the agent program starts, it needs to read this configuration file and perform related initialization work. Unlike the traditional Internet, the probability that the network topology and link configuration in this application scenario will change frequently is low, so it is more efficient to statically assign IDs (which are actually equivalent to IP addresses in traditional Internet application scenarios) and deploy configuration files. When the configuration really needs to be changed, it is only necessary to redraw the topology map and modify the configuration files of some communication nodes. Considering that this step is the only part that requires and is difficult to avoid manual participation, this cost is acceptable.

[0030] In addition, each agent needs to maintain a routing table, which contains the routing information of all other nodes in the network. If the network contains N communication nodes, the length of the routing table maintained by each agent is N-1. Each routing table entry consists of five items (target CPU ID, next hop CPU ID, link ID, distance, time). The target CPU ID and link ID identify which link the data sent to a certain destination should be sent from; the next hop CPU ID identifies the CPU ID number directly connected to the corresponding link; the distance indicates the distance between the current node and the destination, which is expressed as the number of nodes along the way in the current solution implementation; the time represents the time when this routing table entry was last updated, which is used for timeout processing.

[0031] 2. Working Principle

[0032] 1) Initial route establishment

[0033] When the entire network is started, the agent program on each communication node needs to discover the initial route first. The method is as follows:

[0034] e) Each agent sends a routing detection packet, also known as a heartbeat packet, to all links directly connected to it. Its format is (source CPU ID, previous hop CPU ID, distance). In the original heartbeat packet sent by each node, the distance is set to 0.

[0035] f) When a node receives a heartbeat packet from another node, first check whether the corresponding item in the routing table of this node already exists according to the source CPU ID field in the heartbeat packet; if not, directly use the data in this heartbeat packet, write the data in the heartbeat packet (source CPU ID, previous hop CPU ID, distance) into the routing table item (target CPU ID, next hop CPU ID, distance) corresponding to the current node, and at the same time, fill in the link ID field in the routing table item according to the received link ID, and update the time in the routing table item (update to the current time); if it exists, then judge whether the corresponding table item in the routing table has timed out according to the time field and the specified timeout interval (the timeout interval can be set by the configuration file).

[0036] g) If it has timed out, it means that this entry in the routing table has not been updated for too long, and the original routing path may have a fault, so the data in the heartbeat packet is directly used to update the routing table item; otherwise, according to the last hop CPU ID in the heartbeat packet and the next hop CPU ID field in the routing table item, it is determined whether the data of the current routing table item and this heartbeat packet are from the same direct source. Because the last hop CPU ID in the heartbeat packet is to identify its last node on the receiving routing path, and the next hop CPU ID in the routing table item is to identify its next node on the sending route, the meanings represented by these two CPU IDs are actually the same, so if these two IDs are the same, then this heartbeat packet is sent by the same path as last time (when this routing table item is updated).

[0037] h) If the routing table entry and the heartbeat packet data come from the same source, the data in the heartbeat packet is likely to be exactly the same as that in the routing table entry because the network topology usually does not change. In rare cases where the network topology changes, the distance field in the heartbeat packet may change. In either case, because they come from the same source, it can be assumed that the data in the heartbeat packet is actually the latest version of the data in the routing table entry, so the data in the heartbeat packet can be used directly to update the routing table entry and refresh the time in the routing table entry.

[0038] If the routing table entry and the heartbeat packet data come from different sources, it is necessary to make a judgment on the heartbeat packet data: compare the distance field in the heartbeat packet and the routing table. If the distance in the heartbeat packet is greater than the distance recorded in the current routing table, it means that there is more than one path from this node to the target node, that is, there is a loop in this network, and this heartbeat packet is forwarded from a farther path. In order to avoid the heartbeat packet being infinitely forwarded in a ring network, this situation requires the heartbeat packet to be discarded; if there is no corresponding item in the routing table or the distance in the heartbeat packet is less than or equal to the distance recorded in the current routing table, it means that this heartbeat packet is valid and represents the latest data of the nearest route to the destination CPU ID. The current node updates the distance, link, next hop CPU ID and time fields of the routing table.

[0039] In the four cases where the heartbeat packet is used to update the route, the time in the routing table entry needs to be updated to the current time to avoid the timeout mechanism from making a wrong judgment. At the same time, when the heartbeat packet is used to update the route, in order for other nodes to use the heartbeat packet information containing the latest routing data to update their local routes, it is necessary to increase the distance field in the heartbeat packet by one and continue to forward the heartbeat packet, and modify the previous hop ID in the heartbeat packet to its own CPU ID. Then the heartbeat packet will be forwarded to all links except the link that received the packet. The process of establishing the initial route is as follows: Figure 2 shown.

[0040] This routing establishment method provides good support for ring network topologies. If there is a ring in the network and there are multiple paths to a target node, only the closest one will be selected as the routing path for actual communication, and subsequent nodes will also choose this path after forwarding the heartbeat packet; at the same time, by not forwarding data to the source link, the broadcast storm problem caused by the inability to identify the source of the heartbeat packet is avoided.

[0041] 2) Heartbeat detection / routing update

[0042] After the initial route is established, the agent program on each node needs to perform heartbeat detection regularly and broadcast heartbeat packets to indicate that the node is working normally. The process of heartbeat detection is to broadcast heartbeat packets regularly for each node. The processing process of heartbeat packets is the same as the initial route discovery process, which will not be repeated here.

[0043] Considering that compared with traditional computer networks, the node network in the field of embedded and special equipment is highly related to the system architecture and hardware design of the equipment, the network topology will not change frequently. At the same time, the probability of node disconnection in the network is low and the node controllability is strong, so the detection interval can be set longer to avoid taking up too much computing power and link bandwidth, affecting the normal business data exchange efficiency, but in order for the network to detect abnormalities in time, this interval should not be set too long. In actual use, this interval can be dynamically configured through the configuration file, and needs to be set according to the transmission capacity of the link, the CPU processing capacity and the actual business scenario. If the network topology changes or the node or link is disconnected, the timeout mechanism and the process of route discovery-heartbeat detection-route update can ensure that the network can automatically perceive the occurrence of this phenomenon. If there are multiple available routing paths between the source and destination CPUs, and a node or link in the currently used routing path fails, it will automatically switch to another available path after the timeout-heartbeat detection-route update process. And because the route always chooses the closest link, when the fault on the original path is eliminated, the heartbeat detection mechanism can automatically switch the route back to the original shorter path, without any manual intervention, and without restarting or redeploying any nodes and agents in the network. When a node or link on the routing path is continuously in a faulty state and there is no other available path, the data transmission through this node on the routing path will fail, and the corresponding item in the routing table will continue to be in a timeout state. When the application wants to send data to the node whose corresponding item in the routing table is in a timeout state at this time, the agent can return an error to the application.

[0044] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the technical principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A cross-CPU distributed general proxy communication routing self-discovery method, characterized in that: In the method, first, the network topology is obtained, and a globally unique ID is assigned to each CPU and each link; CPUID is used to uniquely identify a communication node and the agent program running on it, and the application program fills in the CPUID of the communication destination for the agent program to use during data transmission; link ID is used to uniquely identify a link; information about CPUID, link ID, and link type is written into each communication node in the form of a configuration file, and when the agent program starts, the configuration file is read and related initialization work is performed; in addition, each agent program maintains a routing table, which contains the routing information of all other nodes in the network; if the network contains N communication nodes, the length of the routing table maintained by each agent program is N-1; each routing table entry consists of five items (target CPUID, next hop CPUID, link ID, distance, time); the target CPUID and link ID identify which link the data sent to a certain destination should be sent from; the next hop CPUID identifies the CPUID number directly connected to the corresponding link; the distance represents the distance between the current node and the destination, expressed in the number of nodes passed; the time represents the time when this routing table entry was last updated, which is used for timeout processing; Secondly, establish the initial route: When the entire network is started, the agent program on each communication node first discovers the initial route, as follows: a) Each agent sends a routing detection packet, also known as a heartbeat packet, to all links directly connected to it. The format is (source CPUID, previous hop CPUID, distance). In the original heartbeat packet sent by each node, the distance is set to 0; B) when certain node receives the heartbeat packet from other nodes, first check whether this node already has corresponding project in the routing table according to the source CPUID field in the heartbeat packet; If not, then directly use the data in this heartbeat packet, write the data (source CPU ID, last hop CPUID, distance) in the routing table item (target CPU ID, next hop CPUID, distance) corresponding to the current node in the heartbeat packet, simultaneously, fill in the link ID field in the routing table item according to the link ID received, and update the time in the routing table item; If existing, then according to the time field and the timeout interval of regulation, judge whether the corresponding table item in the routing table has timed out; c) If timeout has occurred, directly use the data in the heartbeat packet to update the routing table item; otherwise, determine whether the data of the current routing table item and this heartbeat packet come from the same direct source according to the previous hop CPUID in the heartbeat packet and the next hop CPUID field in the routing table item; the previous hop CPUID in the heartbeat packet identifies the previous node on the receiving routing path, and the next hop CPUID in the routing table item identifies the next node on the sending route. If these two IDs are the same, then this heartbeat packet is sent through the same path as last time; d) If the routing table entry and the heartbeat packet data come from the same source, and it is believed that the data in the heartbeat packet is actually the latest version of the data in the routing table entry, the data in the heartbeat packet is directly used to update the routing table entry, and the time in the routing table entry is refreshed at the same time; If the routing table entry and the heartbeat packet data come from different sources, the heartbeat packet data is judged: compare the distance field in the heartbeat packet and the routing table. If the distance in the heartbeat packet is greater than the distance recorded in the current routing table, it means that there is more than one path from this node to the target node, that is, there is a loop in this network, and this heartbeat packet is forwarded from a farther path, then the heartbeat packet is discarded; if there is no corresponding item in the routing table or the distance in the heartbeat packet is less than or equal to the distance recorded in the current routing table, it means that this heartbeat packet is valid and represents the latest data of the nearest route to the destination CPUID. The current node updates the distance, link, next hop CPUID and time fields of the routing table; After the initial route is established, the agent program on each node also performs heartbeat detection at regular intervals and broadcasts heartbeat packets to indicate that the node it is in is working normally.

2. The method according to claim 1, characterized in that During the process of establishing the initial route, in the four cases where the heartbeat packet is used to update the route, the time in the routing table entry is updated to the current time.

3. The method according to claim 2, characterized in that During the process of establishing the initial route, in the four cases where the heartbeat packet is used to update the route, the time in the routing table entry is updated to the current time, the distance field in the heartbeat packet is increased by one, and the heartbeat packet is forwarded, and the previous hop ID in the heartbeat packet is modified to its own CPU ID.

4. The method according to claim 3, characterized in that During the process of establishing the initial route, in the four cases where the heartbeat packet is used to update the route, after the previous hop ID in the heartbeat packet is modified to its own CPUID, the heartbeat packet is forwarded to all links except the link that received the packet.

5. The method according to claim 1, characterized in that The process of heartbeat detection is to broadcast heartbeat packets to each node at a regular interval, and the processing process of heartbeat packets is consistent with the initial route discovery process.

6. The method according to claim 1, characterized in that The heartbeat detection interval is dynamically configured through the configuration file and is set according to the link transmission capacity, CPU processing capacity and actual business scenario needs.

7. The method according to claim 1, characterized in that If the network topology changes or a node or link is disconnected, the timeout mechanism and the process of route discovery-heartbeat detection-route update can ensure that the network can automatically sense the occurrence of this phenomenon; if there are multiple available routing paths between the source and destination CPUs, and a node or link in the currently used routing path fails, it will automatically switch to another available path after the timeout-heartbeat detection-route update process; And because the route always chooses the closest link, when the fault on the original path is eliminated, the heartbeat detection mechanism can automatically switch the route back to the original shorter path without restarting or redeploying any nodes or agents in the network. When a node or link on the routing path is continuously in a faulty state and there is no other available path, data transmission through this node on the routing path will fail, and the corresponding item in the routing table will continue to be in a timeout state; when the application wants to send data to the node whose corresponding item in the routing table is in a timeout state at this time, the agent returns an error to the application.

8. The method according to claim 1, characterized in that The timeout interval can be set by a configuration file.

9. A system for implementing the method according to any one of claims 1 to 7.

10. The system according to claim 9, characterized in that The system is used in network communications.

Images