linux/net/tipc/node.h, branch v3.12.10

tipc: rename supported flag to recv_permitted

2012-11-22T12:50:51Z

Rename the "supported" flag in bclink structure to "recv_permitted" to better reflect what it is used for. When this flag is set for a given node, we are permitted to receive and acknowledge broadcast messages from that node. Convert it to a bool at the same time, since it is not used to store any numerical values. Signed-off-by: Ying Xue Signed-off-by: Jon Maloy Signed-off-by: Paul Gortmaker

tipc: remove supportable flag from bclink structure

2012-11-22T12:50:50Z

The "supportable" flag in bclink structure is a compatibility flag indicating whether a peer node is capable of receiving TIPC broadcast messages. However, all TIPC versions since tipc-1.5, and after the inclusion in the upstream Linux kernel in 2006, support this capability. It is highly unlikely that anybody is still using such an old version of TIPC, let alone that they want to mix it with TIPC-2.0 nodes. Therefore, we now remove the "supportable" flag. Signed-off-by: Ying Xue Signed-off-by: Jon Maloy Signed-off-by: Paul Gortmaker

tipc: compress out gratuitous extra carriage returns

2012-04-30T19:53:56Z

Some of the comment blocks are floating in limbo between two functions, or between blocks of code. Delete the extra line feeds between any comment and its associated following block of code, to be consistent with the majority of the rest of the kernel. Also delete trailing newlines at EOF and fix a couple trivial typos in existing comments. This is a 100% cosmetic change with no runtime impact. We get rid of over 500 lines of non-code, and being blank line deletes, they won't even show up as noise in git blame. Signed-off-by: Paul Gortmaker

tipc: Hide internal details of node table implementation

2012-02-24T22:05:15Z

Relocates information about the size of TIPC's node table index and its associated hash function, since only node subsystem routines need to have access to this information. Note that these changes are essentially cosmetic in nature, and have no impact on the actual operation of TIPC. Signed-off-by: Allan Stephens Signed-off-by: Paul Gortmaker

tipc: Introduce node signature field in neighbor discovery message

2012-02-24T22:05:13Z

Adds support for the new "node signature" in neighbor discovery messages, which is a 16 bit identifier chosen randomly when TIPC is initialized. This field makes it possible for nodes receiving a neighbor discovery message to detect if multiple neighboring nodes are using the same network address (i.e. ), even when the messages are arriving on different interfaces. This first phase of node signature support creates the signature, incorporates it into outgoing neighbor discovery messages, and tracks the signature used by valid neighbors. An upcoming patch builds on this foundation to implement the improved duplicate neighbor detection checking. Signed-off-by: Allan Stephens Signed-off-by: Paul Gortmaker

tipc: Remove obsolete broadcast tag capability

2012-02-06T21:59:18Z

Eliminates support for the broadcast tag field, which is no longer used by broadcast link NACK messages. Signed-off-by: Allan Stephens Signed-off-by: Paul Gortmaker

tipc: Major redesign of broadcast link ACK/NACK algorithms

2012-02-06T21:59:18Z

Completely redesigns broadcast link ACK and NACK mechanisms to prevent spurious retransmit requests in dual LAN networks, and to prevent the broadcast link from stalling due to the failure of a receiving node to acknowledge receiving a broadcast message or request its retransmission. Note: These changes only impact the timing of when ACK and NACK messages are sent, and not the basic broadcast link protocol itself, so inter- operability with nodes using the "classic" algorithms is maintained. The revised algorithms are as follows: 1) An explicit ACK message is still sent after receiving 16 in-sequence messages, and implicit ACK information continues to be carried in other unicast link message headers (including link state messages). However, the timing of explicit ACKs is now based on the receiving node's absolute network address rather than its relative network address to ensure that the failure of another node does not delay the ACK beyond its 16 message target. 2) A NACK message is now typically sent only when a message gap persists for two consecutive incoming link state messages; this ensures that a suspected gap is not confirmed until both LANs in a dual LAN network have had an opportunity to deliver the message, thereby preventing spurious NACKs. A NACK message can also be generated by the arrival of a single link state message, if the deferred queue is so big that the current message gap cannot be the result of "normal" mis-ordering due to the use of dual LANs (or one LAN using a bonded interface). Since link state messages typically arrive at different nodes at different times the problem of multiple nodes issuing identical NACKs simultaneously is inherently avoided. 3) Nodes continue to "peek" at NACK messages sent by other nodes. If another node requests retransmission of a message gap suspected (but not yet confirmed) by the peeking node, the peeking node forgets about the gap and does not generate a duplicate retransmit request. (If the peeking node subsequently fails to receive the lost message, later link state messages will cause it to rediscover and confirm the gap and send another NACK.) 4) Message gap "equality" is now determined by the start of the gap only. This is sufficient to deal with the most common cases of message loss, and eliminates the need for complex end of gap computations. 5) A peeking node no longer tries to determine whether it should send a complementary NACK, since the most common cases of message loss don't require it to be sent. Consequently, the node no longer examines the "broadcast tag" field of a NACK message when peeking. Signed-off-by: Allan Stephens Signed-off-by: Paul Gortmaker

tipc: Ensure broadcast link re-acquires node after link failure

2012-02-06T21:59:16Z

Fix a bug that can prevent TIPC from sending broadcast messages to a node if contact with the node is lost and then regained. The problem occurs if the broadcast link first clears the flag indicating the node is part of the link's distribution set (when it loses contact with the node), and later fails to restore the flag (when contact is regained); restoration fails if contact with the node is regained by implicit unicast link activation triggered by the arrival of a data message, rather than explicitly by the arrival of a link activation message. The broadcast link now uses separate fields to track whether a node is theoretically capable of receiving broadcast messages versus whether it is actually part of the link's distribution set. The former member is updated by the receipt of link protocol messages, which can occur at any time; the latter member is updated only when contact with the node is gained or lost. This change also permits the simplification of several conditional expressions since the broadcast link's "supported" field can now only be set if there are working links to the associated node. Signed-off-by: Allan Stephens Signed-off-by: Paul Gortmaker

tipc: rename struct link* to struct tipc_link*

2011-12-30T02:53:30Z

This converts the following: struct link -> struct tipc_link struct link_req -> struct tipc_link_req struct link_name -> struct tipc_link_name Signed-off-by: Paul Gortmaker

tipc: Ensure both nodes recognize loss of contact between them

2011-09-18T02:55:03Z

Enhances TIPC to ensure that a node that loses contact with a neighboring node does not allow contact to be re-established until it sees that its peer has also recognized the loss of contact. Previously, nodes that were connected by two or more links could encounter a situation in which node A would lose contact with node B on all of its links, purge its name table of names published by B, and then fail to repopulate those names once contact with B was restored. This would happen because B was able to re-establish one or more links so quickly that it never reached a point where it had no links to A -- meaning that B never saw a loss of contact with A, and consequently didn't re-publish its names to A. This problem is now prevented by enhancing the cleanup done by TIPC following a loss of contact with a neighboring node to ensure that node A ignores all messages sent by B until it receives a LINK_PROTOCOL message that indicates B has lost contact with A, thereby preventing the (re)establishment of links between the nodes. The loss of contact is recognized when a RESET or ACTIVATE message is received that has a "redundant link exists" field of 0, indicating that B's sending link endpoint is in a reset state and that B has no other working links. Additionally, TIPC now suppresses the sending of (most) link protocol messages to a neighboring node while it is cleaning up after an earlier loss of contact with that node. This stops the peer node from prematurely activating its link endpoint, which would prevent TIPC from later activating its own end. TIPC still allows outgoing RESET messages to occur during cleanup, to avoid problems if its own node recognizes the loss of contact first and tries to notify the peer of the situation. Finally, TIPC now recognizes an impending loss of contact with a peer node as soon as it receives a RESET message on a working link that is the peer's only link to the node, and ensures that the link protocol suppression mentioned above goes into effect right away -- that is, even before its own link endpoints have failed. This is necessary to ensure correct operation when there are redundant links between the nodes, since otherwise TIPC would send an ACTIVATE message upon receiving a RESET on its first link and only begin suppressing when a RESET on its second link was received, instead of initiating suppression with the first RESET message as it needs to. Note: The reworked cleanup code also eliminates a check that prevented a link endpoint's discovery object from responding to incoming messages while stale name table entries are being purged. This check is now unnecessary and would have slowed down re-establishment of communication between the nodes in some situations. Signed-off-by: Allan Stephens Signed-off-by: Paul Gortmaker