Routing information reconstruction method and device

Abstract

The present application provides a method and apparatus for reconstructing routing information, which is applied to a device node in a Shak Bus network based on the Shak Bus protocol. The method comprises: receiving a first routing detection packet, determining a target port in the device node that receives the first routing detection packet, wherein the first routing detection packet is a data packet broadcasted by the source device node of the first routing detection packet after confirming that a routing reconstruction condition is satisfied; obtaining a first node identifier of the source device node and a target routing hop count recorded in the first routing detection packet; querying a historical routing hop count corresponding to the target port and the first node identifier from a routing table of the device node; and if the historical routing hop count is greater than the target routing hop count, updating the historical routing hop count corresponding to the target port and the first node identifier in the routing table to the target routing hop count. The solution of the present application enables a device node in a Shak Bus network to update the routing information maintained by the device node.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a method and device for reconstructing routing information. Background Art

[0002] The Shak Bus network, known as the Free Topology Automatic Reconfiguration Network, is a next-generation, high-reliability fieldbus network that offers high speed, strong real-time performance, and multi-path redundancy. Due to its specially designed network structure, the Shak Bus network enables highly reliable end-to-end transmission and supports multi-terminal parallel transmission within the network, increasing overall network throughput.

[0003] In a Shak Bus network, device nodes, such as switches and terminal devices, are connected via a physical bus that complies with the Shak Bus protocol. Changes in the Shak Bus network's connectivity, such as the addition of a new device node, a device node failure, or a fault in the connection lines between device nodes, may necessitate reconfiguration of routing information between the device nodes. Therefore, implementing routing information reconfiguration in a Shak Bus network is a technical challenge facing those skilled in the art. Summary of the Invention

[0004] The present application provides a routing information reconstruction method and apparatus, so that a device node in a Shaker bus network can automatically update the routing information maintained by the device node.

[0005] In one aspect, the present application provides a routing information reconstruction method, which is applied to a device node in a Shak Bus network based on the Shak Bus protocol, wherein the Shak Bus network includes: a plurality of device nodes connected via a physical bus based on the Shak Bus protocol, the method comprising:

[0006] receiving a first routing detection packet, and determining a destination port of the device node that has received the first routing detection packet, wherein the first routing detection packet is a data packet sent in a broadcast form by the source device node of the first routing detection packet when confirming that a routing reconstruction condition is met;

[0007] Obtaining a first node identifier of the source device node and a target route hop count recorded in the first route detection packet, where the target route hop count indicates the number of device nodes that the first route detection packet needs to pass through from the source device node to the device node;

[0008] Querying a historical routing hop count corresponding to the target port and the first node identifier from a routing table of the device node;

[0009] If the historical routing hop count is greater than the target routing hop count, the historical routing hop count corresponding to the target port and the first node identifier in the routing table is updated to the target routing hop count.

[0010] In a possible implementation, the method further includes:

[0011] If the historical routing hop count corresponding to the target port and the first node identifier does not exist in the routing table, the corresponding relationship between the target port, the first node identifier and the target routing hop count is recorded in the routing table.

[0012] In yet another possible implementation, the method further includes:

[0013] If the historical routing hop count is greater than the target routing hop count or the historical routing hop count does not exist in the routing table, the target routing hop count in the first routing detection packet is increased by one to obtain an updated first routing detection packet;

[0014] The updated first route detection packet is sent from a non-vacant port of the device node except the target port, so as to forward the updated first route detection packet to other device nodes in the Shaker bus network.

[0015] In yet another possible implementation, the method further includes:

[0016] When the device node confirms that the routing reconstruction condition is met, constructing a second routing detection packet, wherein the second routing detection packet records the second node identifier of the device node and the routing hop count initialized to 0;

[0017] The second routing detection packet is sent from each non-vacant port of the device node in a broadcast form.

[0018] In a possible implementation, the device node confirming that the routing reconstruction condition is satisfied includes at least one of the following:

[0019] The device node confirms that each device node in the Shaq bus network has completed powering on;

[0020] The device node confirms that a port state of at least one port in the device node changes;

[0021] The device node determines the current arrival of the routing reconstruction time according to the set routing reconstruction period;

[0022] The device node detects that its device address has changed;

[0023] The device node detects a routing reconstruction instruction input by a user;

[0024] The device node receives a routing reconstruction command sent by other device nodes in the Shak bus network.

[0025] In yet another possible implementation, the method further includes:

[0026] When the device node confirms that the port status of at least one port in the device node has changed, the device address of the device node has changed, or a route reconstruction instruction input by a user is detected, a route reconstruction command is sent to other device nodes in the Shaker bus network.

[0027] In another aspect, the present application further provides a routing information reconstruction apparatus, which is applied to a device node in a Shak bus network based on the Shak bus protocol, wherein the Shak bus network includes: a plurality of device nodes connected via a physical bus based on the Shak bus protocol, the apparatus comprising:

[0028] a port confirmation unit, configured to receive a first routing detection packet and determine a target port in the device node that receives the first routing detection packet, wherein the first routing detection packet is a data packet broadcasted by the source device node of the first routing detection packet when confirming that a routing reconstruction condition is met;

[0029] a packet parsing unit, configured to obtain a first node identifier of the source device node and a target route hop count recorded in the first route detection packet, wherein the target route hop count indicates the number of device nodes that the first route detection packet needs to pass through from the source device node to the device node;

[0030] A table query unit, configured to query a historical routing hop count corresponding to the target port and the first node identifier from a routing table of the device node;

[0031] A table updating unit is configured to update the historical routing hop count corresponding to the target port and the first node identifier in the routing table to the target routing hop count if the historical routing hop count is greater than the target routing hop count.

[0032] In a possible implementation, the device further includes:

[0033] The information adding unit is configured to record the correspondence between the target port, the first node identifier and the target routing hop count in the routing table if the historical routing hop count corresponding to the target port and the first node identifier does not exist in the routing table.

[0034] In yet another possible implementation, the apparatus further includes:

[0035] a hop count increasing unit, configured to, if the historical route hop count is greater than the target route hop count or the historical route hop count does not exist in the routing table, increase the target route hop count in the first route detection packet by one to obtain an updated first route detection packet;

[0036] The packet forwarding unit is configured to send the updated first route detection packet from a non-vacant port of the device node except the target port, so as to forward the updated first route detection packet to other device nodes in the Shaker bus network.

[0037] In yet another possible implementation, the apparatus further includes:

[0038] a packet construction unit, configured to construct a second route detection packet when the device node confirms that the route reconstruction condition is satisfied, wherein the second route detection packet records a second node identifier of the device node and a route hop count initialized to 0;

[0039] The packet broadcast unit is configured to send the second routing detection packet from each non-vacant port of the device node in a broadcast form.

[0040] As can be seen from the above, in the embodiment of the present application, the device nodes in the Shak bus network can send out routing detection packets in a broadcast form after confirming that the routing reconstruction conditions are met. After any device node in the Shak bus network receives the routing detection packet broadcast by other device nodes, it can determine the target port in the device node that receives the routing detection packet, and obtain the node identifier of the source device node and the target routing hop count recorded in the routing detection packet. On this basis, if the routing hop count corresponding to the target port and the node identifier of the source device node recorded in the routing table of the device node is greater than the target routing hop count, it is confirmed that there is an update in the routing path from the source device node to the target port, and the routing hop count corresponding to the target port and the node identifier of the source device node in the routing table is updated to the target routing hop count, thereby realizing the update and reconstruction of the routing information in the device nodes of the Shak bus network, so that the device nodes of the Shak bus network can maintain the latest routing information. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without any creative work.

[0042] Figure 1-Figure 3 Schematic diagrams of different network topologies of the Shaker bus network provided in the embodiments of the present application are respectively shown;

[0043] Figure 4 A schematic diagram of a process flow of a routing information reconstruction method provided in an embodiment of the present application is shown;

[0044] Figure 5A schematic diagram showing a process interaction of the routing information reconstruction method provided in an embodiment of the present application is shown;

[0045] Figure 6 A schematic diagram of the structure of a routing information reconstruction device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0046] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0047] The solution of the present application is applied to a Shak bus network based on the Shak bus protocol. To facilitate understanding, the Shak bus protocol used by the Shak bus network in the present application and the possible network topology of the Shak bus network are briefly described first.

[0048] In the Shak bus protocol, all information processing and transmission uses a unified 10-byte frame, also known as a base packet. Because the Shak bus protocol uses 10 bytes per packet, the data packets are relatively short, and the number of bytes in different packets is the same. This makes it easy to control the timing of packet reception and transmission during Shak bus transmission, ensuring high determinism.

[0049] The Shaker bus protocol specifies that message packets are used to transmit command, status, and response information in the network, and are defined using a single base packet. In addition to specially defined packet structures, the structure of a message packet can be as shown in the following table 1:

[0050] Table 1

[0051] Mode Domain Source address field Destination address field Parameter domain 1 Parameter domain 2 Control domain Verification Field 1 byte 2 bytes 2 bytes 1 byte 2 bytes 1 byte 1 byte Mode Word DID1 DID2 Parameter 1 Parameter 2 Control Information CRC check

[0052] In the Shak bus protocol, message packets can be divided into internal message packets, external message packets, and user-defined message packets according to their purpose.

[0053] Among them, internal message packets are used for message interaction between devices within the network. The purpose is to maintain network consistency and implement various built-in functions, including port detection, automatic reconstruction, time synchronization, group messaging and other functions.

[0054] External message packets are functional message packets and responses built into the network that can be called by users. They implement functions such as reading the device address (also known as the device identity, DID) of the device node within the Shaker bus network, obtaining network timestamps, reading and writing network device registers, sending group commands, reading routing tables, pathfinding, setting priority paths, forcing network reconfiguration, and network monitoring.

[0055] User-defined message packets are user-defined messages starting with 0xE0 to 0xFF that can be used in applications. User-defined message packets can follow the format requirements of the message packets provided in Table 1 above.

[0056] The Shaq bus protocol also defines multiple device addresses for device nodes, which may include: device physical address (physical identification, PID), device logical address (logical identification, LID) and network address (device identification, DID).

[0057] The Shaq bus protocol uses a 16-bit device physical address to identify a device. The device physical address is a default identifier set before the device node leaves the factory, cannot be changed, and is unique in the network.

[0058] The ShakBus protocol allows users to temporarily change device addresses during ShakBus network operation by configuring registers. The changed device address is the device's logical address. Modifying a device's logical address triggers a ShakBus network rerouting. Only after the ShakBus network rerouting is complete will the device's logical identity take effect.

[0059] The intra-network address is the current address used by a device node. When the device's logical address is in effect, the intra-network address serves as the device's logical identifier. When the device's logical address is not in effect, the intra-network address serves as the device's physical address. The intra-network address of a device node is also unique within the Shaker bus network.

[0060] Of course, the Shak bus protocol also defines relevant information such as address mask and group management. Since the Shak bus protocol is a currently used network protocol, this application will not elaborate on the specific protocol content of the Shak bus protocol.

[0061] The following is a brief introduction to the composition and network topology of the Shaker bus network.

[0062] The Shak bus network includes: multiple device nodes connected via a physical bus based on the Shak bus protocol.

[0063] Device nodes in the Shak bus protocol can be divided into two categories: intermediate devices and terminal devices.

[0064] The intermediate device may be a switch or a router, and generally has multiple ports, for example, up to 32 ports. Each port is an interface that complies with the Shaker bus protocol and has full-duplex communication capabilities, supporting synchronous data transmission and reception.

[0065] Each port in the intermediate device can support the access of other intermediate devices as well as the access of terminal devices. Based on this, and based on the characteristics of the ports in the intermediate devices in the Shak Bus network, the Shak Bus network not only supports the layer-by-layer cascading of multiple intermediate devices to build a tree network, but also supports other forms of connection between multiple intermediate devices, so that the network topology of the Shak Bus network can be any mesh network structure. For example, the intermediate device nodes in the Shak Bus network can build a point-to-point network, or be connected to each other to form a ring network, etc., without any restrictions.

[0066] In a Shak Bus network, a terminal device typically has two ports. The ports mentioned in this application refer to ports that support the Shak Bus protocol. Terminal devices can connect to each other, as well as to intermediate devices, through ports. While terminal devices can connect to each other through ports, in order to achieve network link expansion or high-reliability network redundancy, terminal devices can also be connected through intermediate devices.

[0067] It is understandable that the intermediate device is mainly responsible for forwarding data packets such as message packets sent by the terminal device. Therefore, all ports in the intermediate device are ports that support the Shaker bus protocol.

[0068] In addition to having a port for the Shaq bus protocol, the terminal device may also have interfaces supporting other protocols, without limitation. For example, the terminal device may also communicate data with other devices in the network or local devices via other protocols to implement local functions.

[0069] It is understandable that the specific types of terminal devices can vary depending on the application scenarios of the Shak Bus network. For example, if the Shak Bus network is used in the field of industrial control, the terminal devices can be detection equipment used in the industrial field to detect machine tools or production lines, as well as monitoring equipment connected to the detection equipment via the Shak Bus network. For another example, if the Shak Bus network is used within the home, the terminal devices in the Shak Bus network can be smart home appliances such as smart washing machines and smart refrigerators. Of course, the Shak Bus network can also have other application scenarios, which will not be elaborated here.

[0070] As can be seen from the above description, the network topology of the Shaker bus network can be any network topology. To facilitate understanding, the following briefly describes several network topologies applicable to the Shaker bus network as examples.

[0071] like Figure 1 , which shows a schematic diagram of a network topology structure of the Shak bus network in this application.

[0072] Figure 1 The Shaq bus network is a tree-like network structure formed by cascading multiple device nodes. Figure 1 The network includes 7 intermediate devices, for example, these 7 intermediate devices are intermediate device 1 to intermediate device 7, and these 7 intermediate devices are connected in a layer-by-layer cascade manner. For example, intermediate device 4 and intermediate device 5 are cascaded with intermediate device 2 through their respective ports, and intermediate device 2 is further cascaded with intermediate device 1, so that intermediate device 1 is at the top layer of the tree-like network structure.

[0073] exist Figure 1 The middle terminal device is located at the bottom of the tree structure network, for example, middle device 4, middle device 5, middle device 6 and middle device 7 can be connected to one or more terminal devices, such as Figure 1 In the example, the terminal devices include terminal device 1 to terminal device 8.

[0074] It should be noted that Figure 1 In the example, each intermediate device located at the third layer from top to bottom is connected to two terminal devices. However, in actual applications, the intermediate device can be connected to only one terminal device, or can be connected to three or even more terminal devices as needed, without restriction.

[0075] in addition, Figure 1 The description is made by taking the terminal device located at the bottom layer of the tree-structured network as an example. In actual applications, the terminal device may also be located at other layers of the tree-structured network without restriction.

[0076] Depend on Figure 1 It can be seen that if a terminal device needs to communicate with other terminal devices, the communication can be forwarded to the corresponding terminal device layer by layer through the intermediate device connected to the terminal device.

[0077] but Figure 1 The Shaker bus network shown in the figure is a topology without redundant connections. This network topology offers a simple structure, few lines, and simplified construction, which can reduce costs. However, it also has significant drawbacks: a failure in a device node in the network can cause the network to malfunction, resulting in low reliability.

[0078] For example, if Intermediary 4 fails, then End Device 1 will be unable to communicate with other Intermediary Devices or End Devices. Alternatively, if Intermediary 2 fails, then Intermediary 4 and Intermediary 5 will become two separate routing vertices, and the End Devices connected to Intermediary 4 and Intermediary 5 will be unable to communicate with other device nodes in the Shaker Bus network.

[0079] In order to improve the reliability of the Shak Bus network and minimize the impact of a single device node failure on the communication between other device nodes in the Shak Bus network, the Shak Bus network can also have a redundant topology.

[0080] like Figure 2 As shown, it shows another network topology diagram of the Shak bus network.

[0081] Figure 2 The network topology and Figure 1 Similar to the above, both belong to the tree network structure formed by the cascade connection of device nodes. Figure 2 There may be multiple pairs of port connections between different device nodes, so that two device nodes can have two or more line connections.

[0082] For example, in Figure 2 In the example, intermediate device 5 is not only connected to intermediate device 2 via the Shak bus, but also connected to intermediate device 3 via the Shak bus. On this basis, if intermediate device 2 fails, intermediate device 5 can also communicate with other device nodes in the network through intermediate device 3.

[0083] Similarly, the terminal device 7 is not only connected to the intermediate device 7 through the Shak bus, but also connected to the intermediate device 3 through the Shak bus. On this basis, if the intermediate device 7 fails, although the terminal device 7 cannot communicate with other device nodes through the intermediate device 7, the intermediate device 3 is still in a normal state, so that the connection line between the terminal device 7 and the intermediate device 3 has not failed. Therefore, the terminal device 7 can still communicate with other device nodes through the intermediate device 3.

[0084] certainly, Figure 2 The situation where there are redundant connections between other device nodes is also involved, which will not be introduced one by one.

[0085] It is understandable that Figure 1 and Figure 2 The example of a Shak Bus network is described by cascading device nodes layer by layer. In practical applications, the Shak Bus network can also be any other network topology, such as a ring network or a mesh network, or a combination of multiple network topologies or any other network topology.

[0086] like Figure 3 , which shows another network topology diagram of the Shak bus network in this application.

[0087] exist Figure 3 The connection between device nodes is a relatively random one.

[0088] like Figure 3 It can be seen that the Shak bus network includes 8 intermediate devices, which are respectively called intermediate device 11, intermediate device 12, intermediate device 13, intermediate device 14, intermediate device 15, intermediate device 16, intermediate device 17 and intermediate device 18.

[0089] Each intermediate device has multiple ports, such as Figure 3 In the example, each intermediate device includes 32 ports using the Shaker bus protocol. These 32 ports are named P0 to P31, where Px and Pr are any two ports among the 32 ports. Each intermediate device can be connected to one or more other intermediate devices.

[0090] exist Figure 3 The network also includes four terminal devices, namely terminal device 11, terminal device 12, terminal device 13 and terminal device 14. Figure 3 In the example, each terminal includes two ports supporting the Shaker bus protocol, and the two ports are respectively called port P0 and port P1.

[0091] Each terminal device can be connected to one or more intermediate devices. Figure 3 As shown, the port P0 of the terminal device 11 is connected to the port Pr of the intermediate device 15 via the Shaker bus, so that the terminal device 11 and the intermediate device 15 have a communication connection. At the same time, the port P1 of the terminal device 11 is also connected to the port Pr of the intermediate device 13 via the Shaker bus. For the connection relationship between other terminal devices and intermediate devices, please refer to Figure 3 , no more details.

[0092] certainly, Figures 1 to 3 Three network topologies of the Shaker bus network are used as examples for illustration. In this application, there is no limitation on the specific network topology of the Shaker bus network.

[0093] The following is an introduction to the routing information reconstruction method provided in the embodiment of the present application.

[0094] like Figure 4 , shows a flow chart of a routing information reconstruction method provided by an embodiment of the present application. The method of this embodiment is applied to any device node in a Shak Bus network based on the Shak Bus protocol. The method of this embodiment may include:

[0095] S401: Receive a first routing detection packet and determine a target port in a device node that receives the first routing detection packet.

[0096] The first route detection packet is a data packet broadcasted by a device node other than the device node after confirming that a route reconstruction condition is met. The device node that sends the first route detection packet is the source device node of the first route detection packet. The first route detection packet is used to assist in determining the number of route hops from the other device nodes to the source device node.

[0097] For the sake of distinction, the route detection packet received by the device node from a device node other than the device node is called a first route detection packet, and the route detection packet subsequently sent by the device node is called a second route detection packet.

[0098] The first route detection packet and the subsequent second route detection packet may both belong to the aforementioned message packets.

[0099] In this application, for the sake of distinction, the port in the device node that receives the first routing detection packet is referred to as the target port.

[0100] It is understandable that different device nodes in the Shak bus network are interconnected through ports, and a device node can receive various data packets from other device nodes through its port. On this basis, after the source device node sends the first routing detection packet in a broadcast form, the first routing detection packet may be transmitted to the device node through multiple different paths, so that the device node may receive the first routing detection packet from multiple different ports. Based on this, in order to subsequently determine which path or port is the shortest to receive the first routing detection packet, it is necessary to determine the target port of the device node that receives the first routing detection packet each time the first routing detection packet is received, so as to subsequently analyze which port in the device node has the shortest routing path to receive the first routing detection packet from the source device node.

[0101] S402: Obtain the first node identifier of the source device node and the target route hop count recorded in the first route detection packet.

[0102] The target routing hop count may also be referred to as routing path length, which indicates the number of device nodes (also referred to as hop count) that the first routing detection packet needs to pass through from the source device node that sends the first routing detection packet to the device node.

[0103] For ease of distinction, the node identifier that uniquely identifies the source device node is referred to as the first node identifier. For example, the first node identifier of the source device node can be the device identifier (DID) of the source device node, or the physical identifier (PID) of the source device node, or other identification information, without limitation.

[0104] The target route hop count refers to the route hop count recorded in the first route detection packet.

[0105] In the present application, the source device node may record a target route hop count with an initial value of 0 in the first route detection packet. The target route hop count in the first route detection packet will gradually increase with the number of device nodes that the first route detection packet passes through. Specifically, after receiving the first route detection packet, if each device node determines that it needs to forward the first route detection packet, then before forwarding the first route detection packet, the target route hop count recorded in the first route detection packet will be increased by one. This will be described in detail later and will not be repeated here.

[0106] S403: Query the historical routing hop count corresponding to the target port and the first node identifier of the source device node from the routing table of the device node.

[0107] It is understandable that, because different ports of a device node can connect to different other device nodes, the routing paths from different ports of the device node to the same other device node are also different. When the device node sends a data packet to a destination device node, it needs to determine the shortest routing path from the device node to the destination device node. In this application, the device node only needs to be concerned with which port of the device node has the shortest path required to send the data packet to the destination device node, that is, the minimum number of routing hops.

[0108] On this basis, the routing table of the device node may record the routing hop counts from each port of the device node to other different device nodes.

[0109] For example, if the device node is device node a, then the routing information from port a1 in device node a to device node b can be expressed as: port a1 - device node b - routing hop count: 5, which means that the routing hop count for transmitting a data packet from port a1 of device node a to device node b is 5.

[0110] Of course, the device node a may also record the routing hop counts from other ports to the device node b, the routing hop counts from port a1 in the device node to other device nodes, and the routing hop counts from other ports to other device nodes, which will not be described in detail.

[0111] In this application, for the sake of distinction, the routing hop count corresponding to the target port and the first node identifier of the source device node queried from the routing table is referred to as the historical routing hop count.

[0112] S404: If the historical routing hop count is greater than the target routing hop count, update the historical routing hop count corresponding to the target port and the first node identifier in the routing table to the target routing hop count.

[0113] It is understood that the first route detection packet is transmitted from the source device node to the target port of the device node. The target route hop count currently recorded in the first route detection packet represents the number of hops required from the source device node to the target port of the device node, as currently determined through detection. The historical route hop count recorded in the routing table is the number of hops required from the source device node to the target port of the device node, as determined prior to the current moment.

[0114] Based on this, if the historical routing hop count recorded in the routing table is greater than the target routing hop count, it means that the historical routing hop count in the routing table cannot accurately reflect the shortest routing hop count currently required from the source device node to the target port of the device node. Therefore, in order to ensure the accuracy of the routing information in the routing table, the routing hop count corresponding to the target port and the first node identifier of the source device node needs to be updated to the target routing hop count.

[0115] Of course, if the historical routing hop count is not greater than the target routing hop count, there is no need to update the historical routing hop count corresponding to the target port and the first node identifier of the source device node in the routing table.

[0116] It is understood that if no historical routing hop count corresponding to the target port and the first node identifier of the source device node is found in the routing table, it means that routing information from the source device node to the target port of the device node has not been constructed before the current moment. For example, the target port may not have been connected to other electronic devices before (i.e., it is in an idle state), or the source device node may have just been connected to the Shak Bus network. Of course, there may also be other reasons that result in the non-existence of a routing path from the target port to the source device node. In this case, it is necessary to improve the routing table to construct routing information between the target port and the source device node.

[0117] Accordingly, in a possible implementation, if the routing table does not contain a historical routing hop count corresponding to the target port and the first node identifier of the source device node, the routing table records the corresponding relationship between the target port and the first node identifier of the source device node and the target routing hop count.

[0118] It is understandable that the device node may receive the first routing detection packet from the same port multiple times, but at different times, the routing path of the first routing detection packet received by the device node from the same port and transmitted from the source device node to the device node may be different, so that the target routing hop count in the first routing detection packet received through the same port at different times may also be different. However, during the routing information reconstruction process, the solution of the present application can continuously update the routing hop count corresponding to the node identifier of the port and the source device node in the routing table, so that the minimum routing hop count (i.e., the shortest routing path) required for the first routing detection packet to be transmitted from the source device node to the port of the device node can be finally recorded in the routing table.

[0119] As can be seen from the above content, in the embodiment of the present application, the device nodes in the Shak bus network can send out routing detection packets in a broadcast form after confirming that the routing reconstruction conditions are met. After any device node in the Shak bus network receives the routing detection packet broadcast by other device nodes, it can determine the target port in the device node that receives the routing detection packet, and obtain the node identifier of the source device node and the target routing hop count recorded in the routing detection packet. On this basis, if the routing hop count corresponding to the target port and the node identifier of the source device node recorded in the routing table of the device node is greater than the target routing hop count, it is confirmed that there is an update in the routing path from the source device node to the target port, and the routing hop count corresponding to the target port and the node identifier of the source device node in the routing table is updated to the target routing hop count, thereby realizing the update and reconstruction of the routing information in the device nodes of the Shak bus network, so that the device nodes of the Shak bus network can maintain the latest routing information.

[0120] It can be understood that in order to ensure that other device nodes in the Shak bus network can also receive the first routing detection packet sent by the source device node, so that other device nodes can determine the number of routing hops from them to the source device node, in this application, the device node will also increase the target routing hop number in the first routing detection packet by one, and continue to send out the first routing detection packet with the updated target routing hop number.

[0121] Considering that the first routing detection packet is a broadcast data packet, in order to avoid the situation where the first routing detection packet continuously propagates among various device nodes in the Shak Bus network (commonly known as flooding), in one possible implementation, if the historical routing hop count corresponding to the target port and the first node identifier of the source device node in the routing table is greater than the target routing hop count, or if the historical routing hop count corresponding to the target port and the first node identifier of the source device node does not exist in the routing table, the device node will increase the target routing hop count in the first routing detection packet by one to obtain an updated first routing detection packet. The device node will then send the updated first routing detection packet from a non-vacant port of the device node other than the target port to forward the first routing detection packet to other device nodes in the Shak Bus network.

[0122] Among them, the non-vacant ports are ports in the device node that are connected to other device nodes.

[0123] For example, if the historical routing hop count corresponding to the target port and the first node identifier of the source device node in the routing table is greater than the target routing hop count, or the historical routing hop count does not exist in the routing table, the device node can perform related operations such as increasing the target routing hop count in the first routing detection packet by one while updating the historical routing hop count in the routing table or adding the target routing hop count corresponding to the target port and the first node identifier of the source device node.

[0124] Of course, the device node may also perform related operations such as increasing the target routing hop count in the first routing detection packet by one before or after updating the routing table or adding the target routing hop count corresponding to the target port and the first node identifier of the source device node to the routing table. There is no restriction on this.

[0125] It is understandable that if the historical routing hop count corresponding to the first node identifier of the target port and the source device node in the routing table is less than or equal to the target routing port, the first routing detection packet can be discarded. This is because, when the historical routing hop count is greater than or equal to the target routing port, it means that the historical routing hop count corresponding to the first node identifier of the target port and the source device node in the routing table is the latest and shortest routing hop count, that is, there is no update to the shortest routing path from the source device node to the target port of the device node. Based on this, there is no situation where the shortest routing path on other device nodes is affected by changes in the shortest path from the source device node to the target port. On this basis, the first routing detection packet is no longer forwarded, which will not affect the update of routing information in other device nodes and can reduce the occurrence of flooding.

[0126] It will be appreciated that the above embodiments of the present application illustrate an example in which a device node receives a route detection packet sent by another device node. In actual applications, the device node can also construct a route detection packet after confirming that the route reconstruction conditions are met. For ease of distinction, the route detection packet constructed by the device node is referred to as a second route detection packet. The second route detection packet contains the second node identifier of the device node and a route hop count initialized to 0.

[0127] On this basis, the device node broadcasts the second routing detection packet from all non-vacant ports of the device node, allowing other device nodes in the Shaker Bus network to receive the second routing detection packet. The processing of the second routing detection packet by other device nodes is the same as the processing performed by the device node based on the first routing detection packet, and will not be further described.

[0128] There are many situations in which the device node confirms that the routing reconstruction condition is met. For example, the device node confirms that the routing reconstruction condition is met including at least one of the following:

[0129] The device node confirms that each device node in the Shaker bus network has completed power-on;

[0130] The device node confirms that a port state of at least one port in the device node changes;

[0131] The device node determines the current arrival routing reconstruction time according to the set routing reconstruction period;

[0132] The device node detects that its device address has changed;

[0133] The device node detects a routing reconstruction instruction input by a user;

[0134] The device node receives a routing reconstruction command sent by other device nodes in the Shak bus network.

[0135] Among them, after all device nodes in the Shak bus network are powered on uniformly, any device node in the Shak bus network will confirm that the routing path reconstruction conditions are met, so that all device nodes in the Shak bus network will reconstruct the routing paths, thereby solving the problem of constructing the first full-network routing information in the Shak bus network after the Shak bus network is powered on.

[0136] Among them, when the port status of the port in the Shak bus device node changes, it may affect the routing path between some device nodes in the Shak bus network. Based on this, when the port status of the device node changes, the device node sends a routing detection packet to enable other device nodes to update related routing information.

[0137] Furthermore, in order to ensure that the device node can promptly update the routing information of other device nodes to the port of the device node after the port status changes, the device node can also send a routing reconstruction command to other device nodes in the Shak bus network so that other device nodes also confirm that the routing reconstruction conditions are met and send out a routing detection packet.

[0138] Similarly, when the device address of the device node changes, the device node may also send a routing reconstruction command to other device nodes.

[0139] When the device node mentioned above sends the routing reconstruction command, the device node may send the routing reconstruction command outward in a broadcast form, so that all device nodes in the Shaker bus network can receive the routing reconstruction command.

[0140] After a user inputs a routing reconfiguration instruction to a device node, the device node confirms that the routing reconfiguration conditions are met. In this case, the device node may also send a routing reconfiguration command to other device nodes in the Shak Bus network to enable other device nodes in the Shak Bus network to update the relevant routing information in their maintained routing tables. For example, the device node may send the routing reconfiguration command in a broadcast format.

[0141] By triggering the reconfiguration of the entire network's routing information through user-input routing reconfiguration instructions, a user-operated network reconfiguration is achieved. Furthermore, upon receiving the routing reconfiguration instruction, the device node broadcasts the routing reconfiguration command to the entire network, eliminating the need for users to input routing reconfiguration instructions to all device nodes one by one.

[0142] In addition, the routing reconstruction instruction input by the user to the device node is an instruction issued through an external command of the Shak bus network. After receiving the routing reconstruction instruction, the device node can convert the routing reconstruction instruction into a routing reconstruction command within the Shak bus network and broadcast it, thereby realizing the internal and external separation of the Shak bus network, thereby ensuring the security and reliability of the Shak bus network.

[0143] It is understandable that after other device nodes in the Shaker bus network send a routing reconstruction command to the entire network, the device node will naturally receive the routing reconstruction command sent by other device nodes.

[0144] The routing reconfiguration cycle is pre-set, and each device node in the Shak Bus network periodically reconfigures routing information based on the unified routing reconfiguration cycle. Triggering routing path reconfiguration based on the routing reconfiguration cycle can effectively reduce the possibility of routing information on each device node in the Shak Bus network being delayed due to failures or anomalies in other routing reconfiguration methods, thereby reducing routing information confusion in the Shak Bus network.

[0145] In order to facilitate understanding of the solution of the present application and for ease of description, the source device node that sends the first routing detection packet is taken as the first device node, and any device node that receives the second routing detection packet is taken as the second device node as an example, and the routing information reconstruction method of the present application is introduced in combination with a specific implementation.

[0146] like Figure 5 , which shows a schematic diagram of a process interaction of a routing information reconstruction method provided by an embodiment of the present application. The method of this embodiment may include:

[0147] S501: When a first device node in a Shaker bus network confirms that a routing reconstruction condition is met, the first device node constructs a routing detection packet.

[0148] The routing detection packet includes a node identifier corresponding to the first device node serving as a source device node, and the routing detection packet also includes a target routing hop count initialized to 0.

[0149] The routing reconstruction conditions can be found in the previous related introduction and will not be repeated here.

[0150] It can be understood that since the routing detection packet is a data packet constructed and needs to be sent by the first device node, the source device node of the routing detection packet is the first device node. Therefore, the node identifier of the source device node in the routing detection packet is the node identifier of the first device node.

[0151] S502: The first device node sends the routing detection packet from each non-vacant port of the first device node in a broadcast form.

[0152] It is understandable that, since the vacant port is not connected to other device nodes, the vacant port is naturally unable to transmit the first routing detection packet externally.

[0153] Since the value of the target route hop count in the route detection packet is initialized to 0, the target route hop count in the route detection packet sent by the first device node is 0.

[0154] S503: After the second device node in the Shaker bus network receives the route detection packet, the second device node confirms the target port at which the second device node receives the route detection packet.

[0155] S504: The second device node obtains the node identifier of the first device node and the target route hop count recorded in the route detection packet.

[0156] It is understandable that, since the routing detection packet is sent by the first device node, the node identifier of the source device node recorded in the routing detection packet is actually the node identifier of the first device node.

[0157] The target routing hop count indicates the number of device nodes that the routing detection packet needs to pass through from the first device node to the second device node.

[0158] It is understandable that if the route detection packet is directly transmitted from the first device node to the target port of the second device node without passing through other device nodes, then the target route hop count must still be 0.

[0159] If the routing detection packet is transmitted to the second device node by at least one other device node other than the first device node, then since the other device nodes have adjusted the target routing hop count in the routing detection packet before forwarding the routing detection packet, the target routing hop count is a natural number greater than zero, and the specific value is the number of other device nodes (i.e., the hop count) that the routing detection packet has passed through when it is transmitted to the second device node. For example, the first device node first transmits the routing detection packet to device node M, then device node M increases the target routing hop count in the routing detection packet by one, and the target routing hop count in the routing detection packet becomes 1. At this time, device node M forwards the routing detection packet to the second device node, and the target routing hop count in the routing detection packet received by the second device node is 1.

[0160] S505, the second device node queries whether there is a historical routing hop count corresponding to the target port and the node identifier of the first device node in the routing table it maintains. If not, execute step S506; if yes, execute step S507.

[0161] S506: The second device node records the corresponding relationship between the target port, the node identifier of the first device node, and the target routing hop count in the routing table maintained by the second device node, and executes step S509.

[0162] For example, assuming that the target routing hop count is 3, the second device node needs to record in the routing table: target port - node identifier of the first device node - routing hop count: 3.

[0163] S507, the second device node determines whether the historical routing hop count corresponding to the target port and the node identifier of the first device node is greater than the target routing hop count recorded in the routing detection packet. If so, step S508 is executed; if not, the first routing detection packet is discarded.

[0164] It can be understood that when the historical routing hops corresponding to the target port and the node identifier of the first device node are recorded in the routing table, the present application needs to detect whether it is necessary to update the correspondence between the target port, the node identifier of the first device node and the historical routing hops in the routing table. If the target routing hops are greater than the historical routing hops in the correspondence, it means that there is a change in the routing path from the target port of the second device to the first device node, and therefore, the corresponding routing hops need to be updated.

[0165] S508: The second device node updates the historical routing hop count corresponding to the target port and the node identifier of the first device node in the routing table to the target routing hop count.

[0166] S509, the second device node increases the target route hop count in the route detection packet by one, and sends the route detection packet with the target route hop count increased by one from each non-vacant port except the target port, so as to forward the route detection packet to other device nodes in the Shaker bus network.

[0167] It is understandable that steps S508 and S509 are not limited to Figure 5 As shown, in actual application, the order of these two steps can be interchanged or performed simultaneously, and there is no restriction on this.

[0168] It is understood that any device node in the Shak Bus network can function as a first device node to broadcast routing detection packets. Furthermore, any device node in the Shak Bus network can function as a second device node to receive routing detection packets sent by other device nodes and perform related processing such as routing information reconstruction.

[0169] In this application, for any device node in the Shaker bus network, when the device node needs to send a data packet to other device nodes, it determines the node identifier of the destination device node and constructs a data packet with the destination address being the destination device node.

[0170] On this basis, in order to send the data packet to the destination device node using the shortest path, the device node can query the routing table and determine the candidate port associated with the node identifier of the destination device node and corresponding to the minimum number of routing hops. If a candidate port exists, the device node will use the candidate port as the destination candidate port and send the data packet outward from the destination candidate port.

[0171] If the device node determines that there are at least two candidate ports that have the same node identifier as the destination device node and have the smallest routing hop count, then the target candidate port with the smallest port number can be selected from the at least two candidate ports, and the data packet can be sent from the target candidate port.

[0172] After receiving the data packet, other device nodes in the Shak Bus network will also determine the target candidate port for sending the data packet in the same way, so that the data packet can be transmitted to the destination device node using the shortest path.

[0173] For example, assume that the destination device node of a data packet is device node ss. For any device node that sends or transfers the data packet, assume that the routing table of the device node contains the following three corresponding relationships:

[0174] Port 1-device node ss-routing hop count: 3;

[0175] Port 2-device node ss-routing hop count: 5;

[0176] Port 3 - device node ss - routing hop count: 3.

[0177] As can be seen, the minimum number of hops required to send a data packet from this device node to device node ss is 3, and the number of hops required to transmit a data packet from port 1 and port 3 to device node ss is also 3. Therefore, port 1 and port 3 are both candidate ports. In this case, assuming that port 1 has a smaller port number, port 1 can be determined as the target candidate port, and the device node can then send the data packet from port 1.

[0178] Of course, the present application does not impose any restrictions on the specific process of data packet transmission by each device node in the Shaker bus network based on the routing information in the constructed routing table, and will not be further elaborated here.

[0179] Corresponding to the routing information reconstruction method provided in the embodiment of the present application, the present application also provides a routing information reconstruction device.

[0180] like Figure 6 , shows a schematic diagram of the composition structure of a routing information reconstruction device provided by an embodiment of the present application. The device of this embodiment is applied to a device node in a Shak bus network based on the Shak bus protocol. The Shak bus network includes: multiple device nodes connected via a physical bus based on the Shak bus protocol. The device includes:

[0181] The port confirmation unit 601 is configured to receive a first routing detection packet and determine a destination port of the device node that receives the first routing detection packet, wherein the first routing detection packet is a data packet broadcasted by the source device node of the first routing detection packet when confirming that a routing reconstruction condition is met;

[0182] The packet parsing unit 602 is configured to obtain the first node identifier of the source device node and the target route hop count recorded in the first route detection packet, where the target route hop count indicates the number of device nodes that the first route detection packet needs to pass through from the source device node to the device node;

[0183] A table query unit 603 is configured to query a historical routing hop count corresponding to the target port and the first node identifier from a routing table of the device node;

[0184] The table updating unit 604 is configured to update the historical routing hop count corresponding to the target port and the first node identifier in the routing table to the target routing hop count if the historical routing hop count is greater than the target routing hop count.

[0185] In a possible implementation, the device further includes:

[0186] The information adding unit is configured to record the correspondence between the target port, the first node identifier and the target routing hop count in the routing table if the historical routing hop count corresponding to the target port and the first node identifier does not exist in the routing table.

[0187] In yet another possible implementation, the apparatus further includes:

[0188] a hop count increasing unit, configured to, if the historical route hop count is greater than the target route hop count or the historical route hop count does not exist in the routing table, increase the target route hop count in the first route detection packet by one to obtain an updated first route detection packet;

[0189] The packet forwarding unit is configured to send the updated first route detection packet from a non-vacant port of the device node except the target port, so as to forward the first route detection packet to other device nodes in the Shaker bus network.

[0190] In yet another possible implementation, the apparatus further includes:

[0191] a packet construction unit, configured to construct a second route detection packet when the device node confirms that the route reconstruction condition is satisfied, wherein the second route detection packet records a second node identifier of the device node and a route hop count initialized to 0;

[0192] The packet broadcast unit is configured to send the second routing detection packet from each non-vacant port of the device node in a broadcast form.

[0193] In another possible implementation, the device node in the packet construction unit confirms that the routing reconstruction condition is satisfied, including at least one of the following:

[0194] The device node confirms that each device node in the Shaq bus network has completed powering on;

[0195] The device node confirms that a port state of at least one port in the device node changes;

[0196] The device node determines the current arrival of the routing reconstruction time according to the set routing reconstruction period;

[0197] The device node detects that its device address has changed;

[0198] The device node detects a routing reconstruction instruction input by a user;

[0199] The device node receives a routing reconstruction command sent by other device nodes in the Shak bus network.

[0200] In yet another possible implementation, the apparatus further includes:

[0201] The reconstruction trigger unit is used to confirm at the device node that the port status of at least one port in the device node has changed, the device address of the device node has changed, or a route reconstruction instruction input by the user is detected, and send a route reconstruction command to other device nodes in the Shak bus network.

[0202] It is understood that in this application, the terms "first," "second," "third," "fourth," and so on (if any) in the specification and claims and the above-mentioned drawings are used to distinguish similar parts, and are not necessarily used to describe a specific order or sequence. It should be understood that the terms used in this way are interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated herein.

[0203] It should be noted that the various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other. At the same time, the features described in the various embodiments in this specification can be replaced or combined with each other, so that professionals in this field can implement or use this application. For device embodiments, since they are basically similar to method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0204] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.

[0205] The above description of the disclosed embodiments will enable one skilled in the art to implement or use the present application. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application is not limited to the embodiments shown herein, but is intended to conform to the widest scope consistent with the principles and novel features disclosed herein.

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

Claims

1. A routing information reconstruction method, characterized in that: The method is applied to a device node in a Shaq bus network based on the Shaq bus protocol, wherein the Shaq bus network includes: a plurality of device nodes connected via a physical bus based on the Shaq bus protocol, and includes: receiving a first routing detection packet, and determining a destination port of the device node that has received the first routing detection packet, wherein the first routing detection packet is a data packet sent in a broadcast form by the source device node of the first routing detection packet when confirming that a routing reconstruction condition is met; Obtaining a first node identifier of the source device node and a target route hop count recorded in the first route detection packet, where the target route hop count indicates the number of device nodes that the first route detection packet needs to pass through from the source device node to the device node; querying a historical routing hop count corresponding to the target port and the first node identifier from a routing table of the device node, wherein the routing table is used to record routing hop counts from each port of the device node to other different device nodes; If the historical routing hop count is greater than the target routing hop count, updating the historical routing hop count corresponding to the target port and the first node identifier in the routing table to the target routing hop count; When the device node confirms that the port status of at least one port in the device node has changed, the device address of the device node has changed, or a route reconstruction instruction input by a user is detected, a route reconstruction command is sent to other device nodes in the Shack bus network.

2. The routing information reconstruction method according to claim 1, characterized in that: Also includes: If the historical routing hop count corresponding to the target port and the first node identifier does not exist in the routing table, the corresponding relationship between the target port, the first node identifier and the target routing hop count is recorded in the routing table.

3. The routing information reconstruction method according to claim 2, characterized in that: Also includes: If the historical routing hop count is greater than the target routing hop count or the historical routing hop count corresponding to the target port and the first node identifier does not exist in the routing table, incrementing the target routing hop count in the first routing detection packet by one to obtain an updated first routing detection packet; The updated first route detection packet is sent from a non-vacant port of the device node except the target port, so as to forward the updated first route detection packet to other device nodes in the Shaker bus network.

4. The routing information reconstruction method according to claim 1, characterized in that: Also includes: When the device node confirms that the routing reconstruction condition is met, constructing a second routing detection packet, wherein the second routing detection packet records the second node identifier of the device node and the routing hop count initialized to 0; The second routing detection packet is sent from each non-vacant port of the device node in a broadcast form.

5. The routing information reconstruction method according to claim 4, characterized in that: The device node confirms that the routing reconstruction condition is satisfied, including at least one of the following: The device node confirms that each device node in the Shaq bus network has completed powering on; The device node confirms that a port state of at least one port in the device node changes; The device node determines the current arrival of the routing reconstruction time according to the set routing reconstruction period; The device node detects that its device address has changed; The device node detects a routing reconstruction instruction input by a user; The device node receives a routing reconstruction command sent by other device nodes in the Shak bus network.

6. A routing information reconstruction device, characterized in that: The device is applied to a device node in a Shaq bus network based on the Shaq bus protocol, wherein the Shaq bus network includes: a plurality of device nodes connected via a physical bus based on the Shaq bus protocol, and the device includes: a port confirmation unit, configured to receive a first routing detection packet and determine a target port in the device node that receives the first routing detection packet, wherein the first routing detection packet is a data packet broadcasted by the source device node of the first routing detection packet when confirming that a routing reconstruction condition is met; a packet parsing unit, configured to obtain a first node identifier of the source device node and a target route hop count recorded in the first route detection packet, wherein the target route hop count indicates the number of device nodes that the first route detection packet needs to pass through from the source device node to the device node; a table query unit, configured to query a historical routing hop count corresponding to the target port and the first node identifier from a routing table of the device node, wherein the routing table is configured to record routing hop counts from each port of the device node to other different device nodes; A table updating unit, configured to update the historical routing hop count corresponding to the target port and the first node identifier in the routing table to the target routing hop count if the historical routing hop count is greater than the target routing hop count; The reconstruction trigger unit is used to confirm at the device node that the port status of at least one port in the device node has changed, the device address of the device node has changed, or a route reconstruction instruction input by the user is detected, and send a route reconstruction command to other device nodes in the Shak bus network.

7. The routing information reconstruction device according to claim 6, characterized in that: Also includes: The information adding unit is configured to record the correspondence between the target port, the first node identifier and the target routing hop count in the routing table if the historical routing hop count corresponding to the target port and the first node identifier does not exist in the routing table.

8. The routing information reconstruction device according to claim 7, characterized in that: Also includes: a hop count increasing unit, configured to, if the historical route hop count is greater than the target route hop count or the historical route hop count corresponding to the target port and the first node identifier does not exist in the routing table, increase the target route hop count in the first route detection packet by one to obtain an updated first route detection packet; The packet forwarding unit is configured to send the updated first route detection packet from a non-vacant port of the device node except the target port, so as to forward the updated first route detection packet to other device nodes in the Shaker bus network.

9. The routing information reconstruction device according to claim 6, characterized in that: Also includes: a packet construction unit, configured to construct a second route detection packet when the device node confirms that the route reconstruction condition is satisfied, wherein the second route detection packet records a second node identifier of the device node and a route hop count initialized to 0; The packet broadcast unit is configured to send the second routing detection packet from each non-vacant port of the device node in a broadcast form.

Images