CN113824796B - Token passing method and device - Google Patents

Token passing method and device Download PDF

Info

Publication number
CN113824796B
CN113824796B CN202111235875.6A CN202111235875A CN113824796B CN 113824796 B CN113824796 B CN 113824796B CN 202111235875 A CN202111235875 A CN 202111235875A CN 113824796 B CN113824796 B CN 113824796B
Authority
CN
China
Prior art keywords
port
node
token
request message
ports
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202111235875.6A
Other languages
Chinese (zh)
Other versions
CN113824796A (en
Inventor
林守强
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Macrosan Technologies Co Ltd
Original Assignee
Macrosan Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Macrosan Technologies Co Ltd filed Critical Macrosan Technologies Co Ltd
Priority to CN202111235875.6A priority Critical patent/CN113824796B/en
Publication of CN113824796A publication Critical patent/CN113824796A/en
Application granted granted Critical
Publication of CN113824796B publication Critical patent/CN113824796B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1034Reaction to server failures by a load balancer

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)

Abstract

The application provides a token passing method and device, which are applied to nodes included in a distributed cluster. The distributed cluster comprises a plurality of nodes and at least two token rings, wherein the token passing directions of the token rings are the same, and each node comprises ports which belong to different token rings. Each node has currently chosen to send tokens through its own included first port. In the method, when the node does not receive the token within a preset time period, a second port used for sending the token can be reselected from ports which are included by the node and belong to different token rings, and then the node is switched from the first port to the second port so as to send the token through the second port. In the method, each node can sense the token transmission fault and automatically switch among ports belonging to different token rings, so that the token can be transferred across the token rings, the occurrence probability of brain cracks is reduced, and the stability of the distributed cluster is improved.

Description

Token passing method and device
Technical Field
The present disclosure relates to the field of communications technologies, and in particular, to a token passing method and device.
Background
A distributed cluster typically includes a plurality of nodes, with heartbeats maintained between the nodes by passing tokens to perceive the survival status of other nodes in the cluster. When the network fault token cannot be transmitted, each node considers that other nodes are faulty because the existence of other nodes cannot be perceived, so that the phenomenon that each node strives for resources and the cluster cannot work together as a whole is caused, and the phenomenon is commonly called brain fracture.
To reduce the probability of a cluster developing a brain fracture, multiple token rings (logical channels for passing tokens) are typically deployed in the cluster. Each node includes ports that belong to different token rings. The target node (typically the node with the smallest node identifier in the cluster) is responsible for selecting the token Ring currently used for transmitting the token, for example, ring1, then sends the token to the next node through the corresponding port of Ring1 on the node, and after the next node receives the token through the corresponding port of Ring1 on the node, the next node continues to send the token to the next node through the port, and so on until the token returns to the target node. If any port or link between ports on the current token Ring fails, the target node can select other token rings (for example, ring 2) to continue to transmit tokens, so that the occurrence probability of cluster brain fracture is reduced, and the cluster stability is improved.
However, if all token rings have port or link failures, cluster brain cracks still occur, affecting cluster stability.
Disclosure of Invention
In view of this, the present application proposes a token passing method and apparatus for improving the stability of a distributed cluster.
In order to achieve the purposes of the application, the application provides the following technical scheme:
in a first aspect, the present application provides a token passing method applied to a node included in a distributed cluster, where the distributed cluster includes a plurality of nodes and at least two token rings, where token passing directions of the at least two token rings are the same, each node includes at least two ports that belong to different token rings, and each node has selected to send a token through a first port of the at least two ports included in the node, and the method includes:
if the token is not received within a preset first time period, reselecting a second port for sending the token from at least two ports included in the node;
and switching from the first port to the second port of the node to send the token through the second port.
Optionally, the re-selecting a second port for sending the token from at least two ports included in the node includes:
transmitting a probe request message to a next node along the token passing direction through each port included in the node, so that the next node returns a probe response message to the node through the port receiving the probe request message when receiving the probe request message;
determining at least one third port which receives the probe response message within a preset second time period;
and selecting one port from the at least one third port as the second port.
Optionally, the re-selecting a second port for sending the token from at least two ports included in the node includes:
transmitting a probe request message to a next node along the token passing direction through a first port of the node, so that the next node returns a probe response message to the node through the port receiving the probe request message when receiving the probe request message;
and if the probe response message is received through the first port of the node within a preset second time period, determining the first port as the second port.
Optionally, the method further comprises:
if the first port of the node does not receive the detection response message within a preset second time period, sending detection request messages to the next node through other ports except the first port respectively, so that the next node returns detection response messages to the node through the port receiving the detection request messages when receiving the detection request messages;
determining at least one fourth port which receives the probe response message within a preset second time period;
selecting one port from the at least one fourth port as the second port.
Optionally, the probe request message is a Ping message.
In a second aspect, the present application provides a token passing apparatus applied to a node included in a distributed cluster, where the distributed cluster includes a plurality of nodes and at least two token rings, where token passing directions of the at least two token rings are the same, each node includes at least two ports that belong to different token rings, and each node has selected to send a token through a first port of the at least two ports included in the node, and the apparatus includes:
a selecting unit, configured to reselect a second port for sending a token from at least two ports included in the node if the token is not received within a preset first time period;
and the switching unit is used for switching from the first port to the second port of the node so as to send the token through the second port.
Optionally, the selecting unit reselects a second port for sending the token from at least two ports included in the node, including:
transmitting a probe request message to a next node along the token passing direction through each port included in the node, so that the next node returns a probe response message to the node through the port receiving the probe request message when receiving the probe request message;
determining at least one third port which receives the probe response message within a preset second time period;
and selecting one port from the at least one third port as the second port.
Optionally, the selecting unit reselects a second port for sending the token from at least two ports included in the node, including:
transmitting a probe request message to a next node along the token passing direction through a first port of the node, so that the next node returns a probe response message to the node through the port receiving the probe request message when receiving the probe request message;
and if the probe response message is received through the first port of the node within a preset second time period, determining the first port as the second port.
Optionally, the selecting unit reselects a second port for sending the token from at least two ports included in the node, and the selecting unit further includes:
if the first port of the node does not receive the detection response message within a preset second time period, sending detection request messages to the next node through other ports except the first port respectively, so that the next node returns detection response messages to the node through the port receiving the detection request messages when receiving the detection request messages;
determining at least one fourth port which receives the probe response message within a preset second time period;
selecting one port from the at least one fourth port as the second port.
Optionally, the probe request message is a Ping message.
As can be seen from the above description, in the embodiment of the present application, each node in the cluster can sense the token transmission failure and switch between ports belonging to different token rings by itself, so that token transmission across token rings can be realized, the occurrence probability of brain fracture is reduced, and the stability of the distributed cluster is improved.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a flow chart of a token passing method shown in an embodiment of the present application;
FIG. 2 is a schematic diagram of a distributed cluster according to an embodiment of the present disclosure;
FIG. 3 is a flow chart illustrating an implementation of step 101 in accordance with an embodiment of the present application;
FIG. 4 is a flow chart illustrating another implementation of step 101 according to an embodiment of the present application;
FIG. 5 is a schematic diagram of a post-failure redetermined token passing path shown in an embodiment of the present application;
fig. 6 is a schematic diagram of a token passing apparatus according to an embodiment of the present application.
Detailed Description
Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples are not representative of all implementations consistent with the present application.
The terminology used in the embodiments of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the embodiments of the application. As used in the embodiments of the present application, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any or all possible combinations of one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used in embodiments of the present application to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, the negotiation information may also be referred to as second information, and similarly, the second information may also be referred to as negotiation information, without departing from the scope of embodiments of the present application. The word "if" as used herein may be interpreted as "at … …" or "at … …" or "responsive to a determination", depending on the context.
For the purposes of making the objects, technical solutions and advantages of the embodiments of the present application more apparent, the following detailed description of the embodiments of the present application is performed in conjunction with the accompanying drawings and specific embodiments:
referring to fig. 1, a flow chart of a token passing method is shown in an embodiment of the present application. The flow applies to nodes comprised by the distributed cluster.
The distributed cluster may comprise a plurality of nodes, each node comprising at least two ports, each port belonging to a different token ring, i.e. the nodes in the cluster are connected by a plurality of token rings. The token passing direction of each token ring is the same.
Referring to fig. 2, a schematic structural diagram of a distributed cluster is shown in an embodiment of the present application. The distributed cluster includes 4 nodes, respectively denoted as Node 1-Node 4, each Node including two ports (ports), for example, node1 includes Port11 and Port21, node2 includes Port12 and Port22, node3 includes Port13 and Port23, and Node4 includes Port14 and Port24.
Wherein, port11, port12, port13, port14 constitute token Ring Ring1, port21, port22, port23, port24 constitute token Ring Ring2. The token transmission directions of Ring1 and Ring2 are Node 1- & gt Node 2- & gt Node 3- & gt Node 4- & gt Node1.
As shown in fig. 1, the token passing flow of the embodiment of the present application may include the following steps:
step 101, if no token is received within a preset first period of time, reselecting a second port for sending the token from at least two ports included in the node.
In initial operation, each node may select a default port to send a token, e.g., each node selects a Ring1 corresponding port to send a token on its own node.
The port currently selected by the node for sending the token is referred to herein as the first port. It will be appreciated that the reference to the first port is made for ease of distinction and is not intended to be limiting.
If the port selected by each node and the link corresponding to the port are normal, each node can periodically receive the token. Otherwise, if the node does not receive the token within a preset first period of time (such as 2300 ms), it is considered that the channel (or path) in the cluster for which the token is currently transmitted is abnormal, and the node needs to reselect the port on the node for sending the token.
The reselected port is referred to herein as the second port. It will be appreciated that the term second port is used for convenience of distinction and is not intended to be limiting.
The process of selecting the second port is described below, and is not described in detail herein.
Step 102, switch from the first port to the second port of the node to send the token through the second port.
After each node completes the port switching through the step, the token can be sent through the port reselected by each node, so that the transfer among the nodes of the token is restored.
Thus, the flow shown in fig. 1 is completed.
As can be seen from the flow shown in fig. 1, in the embodiment of the present application, each node may sense token passing abnormality by itself and independently complete port selection and switching. Because each node may independently select a port, and the selected ports may belong to different token rings, token passing across token rings may be achieved. In the implementation mode, even if each token ring has faults, as long as the fault links of each token ring are not concentrated among the same nodes, in other words, only one normal link exists among any adjacent nodes, the token can be transferred among the nodes, so that the running stability of the cluster is ensured, and service interruption is avoided.
The process of selecting the second port by the node in step 101 is described as follows:
as an embodiment, referring to fig. 3, a process for implementing step 101 is shown in an embodiment of the present application.
As shown in fig. 3, the process may include the steps of:
step 301, transmitting a probe request message to the next node along the token passing direction through each port included in the node.
For example, if the current Node is Node1, the next Node along the token passing direction (Node 1→node2→node3→node4→node 1) is Node2.Node1 may send probe request messages to Node2 through Port11 and Port21, respectively.
If the next node receives the probe request message, a probe response message is returned to the node through the port receiving the probe request message. For example, when Node2 receives the probe request message through Port22, it will send a probe response message to Node1 through Port22, and Node1 can receive the probe response message through Port 21.
As an embodiment, the probe request message sent by the present node may be a Ping message to probe whether the next node is reachable through the corresponding link of the current port.
Step 302, determining at least one third port that receives the probe response message within a preset second time period.
When the node receives the probe response message through the port sending the probe request message within a preset second time period (for example, 500 ms), the link corresponding to the port is indicated to be normal.
Here, a port that can receive the probe response message is referred to as a third port. It will be appreciated that the third port is named for ease of distinction and is not intended to be limiting.
All the ports (third ports) of the node which can reach the next node can be determined through the step.
Step 303, selecting one port from the at least one third port as the second port.
As an embodiment, any port that can reach the next node can be selected as the port to be switched (second port).
As another embodiment, since the links corresponding to the first ports of all the nodes are not failed, when it is determined in step 302 that the links corresponding to the first ports on the node are normal, the first port may be preferentially selected as the second port, so that the port switching is not actually performed later, and the existing port (first port) may be maintained to send the token, so as to save the system resources consumed by the port switching.
Thus, the flow shown in fig. 3 is completed.
As can be seen from the flow shown in fig. 3, in the embodiment of the present application, by sending the probe request message to each port in parallel, the port that can reach the next node can be quickly screened out, so as to improve the port switching efficiency.
As another embodiment, referring to fig. 4, another implementation procedure of step 101 is shown in an embodiment of the present application.
As shown in fig. 4, the process may include the steps of:
step 401, transmitting a probe request message to a next node along the token passing direction through a first port of the present node.
In this step, only the corresponding link of the first port currently selected by the node is probed, that is, the probing request message is sent to the next node only through the first port.
If the next node receives the probe request message, a probe response message is returned to the node through the local port receiving the probe request message, and the node can receive the returned probe response message through the first port.
And step 402, if the probe response message is received through the first port of the node within a preset second time period, determining the first port as the second port.
If the node receives the probe response message returned by the next node through the first port, which indicates that the link corresponding to the first port of the node is normal, the next node can be reached through the first port of the node, therefore, the first port can be determined to be the second port, the port switching is not required to be actually executed later, and the existing port (the first port) can be maintained to send the token.
In step 403, if the probe response message is not received through the first port of the node within the preset second period of time, the probe request message is sent to the next node through the other ports except the first port.
If the node does not receive the probe response message returned by the next node through the first port, which indicates that the link corresponding to the first port fails, the step starts the detection of the links corresponding to other ports, namely, the node sends a probe request message to the next node through other ports except the first port.
If the next node receives the probe request message, a probe response message is returned to the node through the port receiving the probe request message, and the node can determine that the next node can be reached through the port according to the port receiving the probe response message.
Step 404, determining at least one fourth port that receives the probe response message within a preset second time period.
Here, the fourth port is a port other than the first port that can receive the probe response message, in other words, the fourth port is a port on the own node that can reach the next node. It will be appreciated that the fourth port is named for ease of distinction and is not intended to be limiting.
I.e. by this step all the ports (fourth port) on the present node that can reach the next node are found.
Step 405, selecting one port from the at least one fourth port as the second port.
In this step, any port that can reach the next node can be selected as the second port.
Since it has been determined that the first port corresponds to a link failure by step 403, after the second port that can reach the next node is selected by this step, a port switch can be performed to resume token passing by step 103.
Thus, the flow shown in fig. 4 is completed.
As can be seen from the flow shown in fig. 4, in the embodiment of the present application, the link to which the first port may have a fault is preferentially detected, and when it is determined that the link to which the first port belongs has no fault, detection on the links corresponding to other ports may be prohibited, so as to reduce network resource consumption.
The token passing process will be described below with reference to the cluster shown in fig. 2.
The cluster shown in fig. 2 may be implemented based on the pacimaker + Corosync architecture. Where Pacemaker is the resource manager and Corosync is part of the cluster management suite, mainly responsible for messaging and membership management.
At the initial running of the cluster, node1 may select Port11 by default to send the token, node2 may select Port12 by default to send the token, node3 may select Port13 by default to send the token, and Node4 may select Port14 by default to send the token.
When the links corresponding to Port 11-Port 14 are normal, tokens are sequentially transmitted along the path Node1, node2, node3, node4 and Node1 in Ring 1. The Node (Node) receiving the token may perform the corresponding traffic processing.
Here, assume that the link between Port12 and Port13 fails, and the link between Port24 and Port21 fails. Wherein, the link failure between Port12 and Port13 may cause each node that passes the token through Ring1 to fail to receive the token within a preset period of time (e.g., 2300 ms), while perceiving that the channel (Ring 1) that passes the token currently fails.
As an embodiment, node1 may send Ping messages to Node2 via Port11 and Port21, respectively, after sensing the failure. The Ping message sent by the Port11 is recorded as Ping1, the source IP address of Ping1 is the IP address of the Port11, and the destination IP address is the IP address of the Port 12; the Ping message sent through Port21 is denoted as Ping2, with the source IP address of Ping2 being the IP address of Port21 and the destination IP address being the IP address of Port 22.
After Node2 receives Ping1 through Port12, it replies response message to Node1 through Port12, the destination IP address of the response message is the IP address of Port11, the source IP address is the IP address of Port 12; after Node2 receives Ping2 through Port22, it replies a response message to Node1 through Port22, the destination IP address of the response message is the IP address of Port21, and the source IP address is the IP address of Port 22.
Node1 receives the response messages through Port11 and Port21 respectively, so that it can be determined that both the link corresponding to Port11 and the link corresponding to Port21 are normal, and then the token can be selected to continue to be sent through Port 11.
Similarly, node2 may send Ping messages to Node3 via Port12 and Port22, respectively, after detecting the failure, denoted as Ping3 (source IP address is the IP address of Port12, destination IP address is the IP address of Port 13) and Ping4 (source IP address is the IP address of Port22, destination IP address is the IP address of Port 23), respectively.
Because of the link failure between the Port12 and the Port13, the Node3 cannot receive the Ping3 sent by the Node2 through the Port13, and the Node2 cannot receive the response message of the Node3 through the Port12, so that the Node2 can determine that the Port12 corresponds to the link failure; while the link between Port22 and Port23 is normal, node3 may receive Ping4 sent by Node2 through Port23, and then, based on Ping4 responding to Node2 with a response message (the source IP address is the IP address of Port23, the destination IP address is the IP address of Port 22), when Node2 receives the response message returned by Node3 through Port22, it is determined that the link corresponding to Port22 is normal, so Node2 chooses to send a token through Port 22. I.e., switch from sending tokens through Port12 to sending tokens through Port 22.
Similarly, after Node3 senses a fault, it may send Ping messages to Node4 through Port23 and Port13, respectively, and the specific process flow may refer to the foregoing process flow of Node1 sending Ping messages to Node2, which is not described herein again. Eventually Node3 maintains sending tokens through Port 13.
Similarly, after Node4 senses a fault, it may send Ping messages to Node1 through Port24 and Port14, respectively, and the specific process flow may refer to the foregoing process flow of Node2 sending Ping messages to Node3, which is not described herein again. Eventually Node4 maintains sending tokens through Port 14.
After the above process is completed, the token may continue to be passed on the redetermined token passing path (the path shown by the dashed line in fig. 5) based on the existing token retransmission mechanism.
It can be seen that although there is a faulty link in Ring1 and Ring2, the normal token transfer can be effectively ensured by the cross token Ring transfer method, so that cluster stability can be improved, the number of cluster reorganization and node restarting is reduced, and service interruption is avoided as much as possible.
The method provided by the embodiment of the present application is described above, and the device provided by the embodiment of the present application is described below:
referring to fig. 6, a schematic structural diagram of an apparatus provided in an embodiment of the present application is applied to a node included in a distributed cluster, where the distributed cluster includes a plurality of nodes and at least two token rings, where token passing directions of the at least two token rings are the same, each node includes at least two ports that belong to different token rings, and each node has selected to send a token through a first port of the at least two ports included in the node, and the apparatus includes: a selection unit 601 and a switching unit 602, wherein:
a selecting unit 601, configured to reselect, if a token is not received within a preset first period of time, a second port for sending the token from at least two ports included in the node;
a switching unit 602, configured to switch from the first port to the second port of the node, so as to send the token through the second port.
As an embodiment, the selecting unit 601 reselects a second port for transmitting a token from at least two ports included in the node, including:
transmitting a probe request message to a next node along the token passing direction through each port included in the node, so that the next node returns a probe response message to the node through the port receiving the probe request message when receiving the probe request message;
determining at least one third port which receives the probe response message within a preset second time period;
and selecting one port from the at least one third port as the second port.
As an embodiment, the selecting unit 601 reselects a second port for transmitting a token from at least two ports included in the node, including:
transmitting a probe request message to a next node along the token passing direction through a first port of the node, so that the next node returns a probe response message to the node through the port receiving the probe request message when receiving the probe request message;
and if the probe response message is received through the first port of the node within a preset second time period, determining the first port as the second port.
As an embodiment, the selecting unit 601 reselects a second port for sending a token from at least two ports included in the node, and further includes:
if the first port of the node does not receive the detection response message within a preset second time period, sending detection request messages to the next node through other ports except the first port respectively, so that the next node returns detection response messages to the node through the port receiving the detection request messages when receiving the detection request messages;
determining at least one fourth port which receives the probe response message within a preset second time period;
selecting one port from the at least one fourth port as the second port.
As an embodiment, the probe request message is a Ping message.
The description of the apparatus shown in fig. 6 is thus completed.
As can be seen from the above description, in the embodiment of the present application, each node may sense token passing abnormality by itself and independently complete port selection and switching. Because each node may independently select a port, and the selected ports may belong to different token rings, token passing across token rings may be achieved. In the implementation mode, even if each token ring has faults, as long as the fault links of each token ring are not concentrated among the same nodes, in other words, only one normal link exists among any adjacent nodes, the token can be transferred among the nodes, so that the running stability of the cluster is ensured, and service interruption is avoided.
The foregoing description of the preferred embodiments is merely exemplary in nature and is not intended to limit the invention to the precise form disclosed, and thus, any modification, equivalents, and alternatives falling within the spirit and scope of the embodiments are intended to be included within the scope of the invention.

Claims (10)

1. A token passing method, applied to a node included in a distributed cluster, the distributed cluster including a plurality of nodes and at least two token rings, the token passing directions of the at least two token rings being identical, each node including at least two ports belonging to different token rings, each node having selected to send a token through a first port of the at least two ports included in itself, the method comprising:
if the token is not received within a preset first time period, reselecting a second port for sending the token from at least two ports included in the node;
and switching from the first port to the second port of the node to send the token through the second port.
2. The method of claim 1, wherein the re-selecting the second port for transmitting the token from at least two ports included in the node comprises:
transmitting a probe request message to a next node along the token passing direction through each port included in the node, so that the next node returns a probe response message to the node through the port receiving the probe request message when receiving the probe request message;
determining at least one third port which receives the probe response message within a preset second time period;
and selecting one port from the at least one third port as the second port.
3. The method of claim 1, wherein the re-selecting the second port for transmitting the token from at least two ports included in the node comprises:
transmitting a probe request message to a next node along the token passing direction through a first port of the node, so that the next node returns a probe response message to the node through the port receiving the probe request message when receiving the probe request message;
and if the probe response message is received through the first port of the node within a preset second time period, determining the first port as the second port.
4. A method as claimed in claim 3, wherein the method further comprises:
if the first port of the node does not receive the detection response message within a preset second time period, sending detection request messages to the next node through other ports except the first port respectively, so that the next node returns detection response messages to the node through the port receiving the detection request messages when receiving the detection request messages;
determining at least one fourth port which receives the probe response message within a preset second time period;
selecting one port from the at least one fourth port as the second port.
5. A method according to any one of claims 2 to 4, wherein the probe request message is a Ping message.
6. A token passing apparatus for use with a node comprised in a distributed cluster, the distributed cluster comprising a plurality of nodes and at least two token rings, the token passing directions of the at least two token rings being identical, each node comprising at least two ports belonging to different token rings, each node having selected to transmit a token through a first port of the at least two ports comprised by itself, the apparatus comprising:
a selecting unit, configured to reselect a second port for sending a token from at least two ports included in the node if the token is not received within a preset first time period;
and the switching unit is used for switching from the first port to the second port of the node so as to send the token through the second port.
7. The apparatus of claim 6, wherein the selecting unit reselects a second port for transmitting the token from at least two ports included in the node, comprising:
transmitting a probe request message to a next node along the token passing direction through each port included in the node, so that the next node returns a probe response message to the node through the port receiving the probe request message when receiving the probe request message;
determining at least one third port which receives the probe response message within a preset second time period;
and selecting one port from the at least one third port as the second port.
8. The apparatus of claim 6, wherein the selecting unit reselects a second port for transmitting the token from at least two ports included in the node, comprising:
transmitting a probe request message to a next node along the token passing direction through a first port of the node, so that the next node returns a probe response message to the node through the port receiving the probe request message when receiving the probe request message;
and if the probe response message is received through the first port of the node within a preset second time period, determining the first port as the second port.
9. The apparatus of claim 8, wherein the selecting unit reselects a second port for transmitting the token from at least two ports included in the node, further comprising:
if the first port of the node does not receive the detection response message within a preset second time period, sending detection request messages to the next node through other ports except the first port respectively, so that the next node returns detection response messages to the node through the port receiving the detection request messages when receiving the detection request messages;
determining at least one fourth port which receives the probe response message within a preset second time period;
selecting one port from the at least one fourth port as the second port.
10. The apparatus according to any of claims 7 to 9, wherein the probe request message is a Ping message.
CN202111235875.6A 2021-10-22 2021-10-22 Token passing method and device Active CN113824796B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111235875.6A CN113824796B (en) 2021-10-22 2021-10-22 Token passing method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111235875.6A CN113824796B (en) 2021-10-22 2021-10-22 Token passing method and device

Publications (2)

Publication Number Publication Date
CN113824796A CN113824796A (en) 2021-12-21
CN113824796B true CN113824796B (en) 2023-06-30

Family

ID=78917264

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111235875.6A Active CN113824796B (en) 2021-10-22 2021-10-22 Token passing method and device

Country Status (1)

Country Link
CN (1) CN113824796B (en)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102647323A (en) * 2012-03-28 2012-08-22 华为技术有限公司 Flow control method and device as well as clustering system
WO2013045509A1 (en) * 2011-09-27 2013-04-04 Alcatel Lucent Method of failure detection in an operating system
EP3402293A1 (en) * 2017-05-12 2018-11-14 R3 - Reliable Realtime Radio Communications GmbH Wireless token ring system mobility
CN109218141A (en) * 2018-11-20 2019-01-15 郑州云海信息技术有限公司 A kind of malfunctioning node detection method and relevant apparatus
CN109450666A (en) * 2018-10-12 2019-03-08 新华三技术有限公司成都分公司 Distributed system network management method and device
CN109525445A (en) * 2018-12-29 2019-03-26 北京东土军悦科技有限公司 Link switch-over method, link redundancy backup network and computer readable storage medium
WO2020001204A1 (en) * 2018-06-28 2020-01-02 中兴通讯股份有限公司 Link backup method and device, and computer readable storage medium

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI355826B (en) * 2007-08-20 2012-01-01 Univ Nat Taiwan Science Tech Data transmitting method with multiple token macha

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013045509A1 (en) * 2011-09-27 2013-04-04 Alcatel Lucent Method of failure detection in an operating system
CN102647323A (en) * 2012-03-28 2012-08-22 华为技术有限公司 Flow control method and device as well as clustering system
EP3402293A1 (en) * 2017-05-12 2018-11-14 R3 - Reliable Realtime Radio Communications GmbH Wireless token ring system mobility
WO2020001204A1 (en) * 2018-06-28 2020-01-02 中兴通讯股份有限公司 Link backup method and device, and computer readable storage medium
CN109450666A (en) * 2018-10-12 2019-03-08 新华三技术有限公司成都分公司 Distributed system network management method and device
CN109218141A (en) * 2018-11-20 2019-01-15 郑州云海信息技术有限公司 A kind of malfunctioning node detection method and relevant apparatus
CN109525445A (en) * 2018-12-29 2019-03-26 北京东土军悦科技有限公司 Link switch-over method, link redundancy backup network and computer readable storage medium

Also Published As

Publication number Publication date
CN113824796A (en) 2021-12-21

Similar Documents

Publication Publication Date Title
RU2423008C2 (en) METHOD AND SYSTEM FOR AUTOMATIC PROTECTION OF Ethernet NETWORK
US8381013B2 (en) Method and apparatus for detecting and handling peer faults in peer-to-peer network
US7924702B2 (en) Method for reconfiguring a communication network
US8797845B2 (en) Failure recovery method in non revertive mode of ethernet ring network
US20060268680A1 (en) Communication network connection failure protection methods and systems
CN101483592B (en) Method and apparatus for inhibiting bidirectional forwarding detection link oscillation
US8711686B2 (en) Packet transmission system and fault recovery method
CN101197733A (en) Automatic detection method and device for network connectivity
US8107358B2 (en) Method, computer program product, and network node element for more quickly detecting faults on transmission paths and/or in nodes
US20130016617A1 (en) Network relay device and control method thereof
JP5618946B2 (en) Communication apparatus and communication system
US9246796B2 (en) Transmitting and forwarding data
US11108623B2 (en) Rapid owner selection
CN113824796B (en) Token passing method and device
US7162544B2 (en) Message transfer method and apparatus
CN107547330B (en) Method and node equipment for transmitting service data
US7023793B2 (en) Resiliency of control channels in a communications network
CN106921568B (en) Network protection method and device
CN114598640A (en) Method and device for link recovery
CN113395188B (en) Method and system for determining working state of server
US7808893B1 (en) Systems and methods for providing redundancy in communications networks
CN105763409A (en) Flow forwarding method and device
JP6301750B2 (en) Relay device
JPH05292125A (en) Bypass route changeover system and switch back system
CN118101516A (en) Message transmission method and device

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant