1. 24 Feb, 2012 6 commits
  2. 06 Feb, 2012 3 commits
    • Allan Stephens's avatar
      tipc: Remove obsolete broadcast tag capability · 1ec2bb08
      Allan Stephens authored
      
      
      Eliminates support for the broadcast tag field, which is no longer
      used by broadcast link NACK messages.
      Signed-off-by: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      1ec2bb08
    • Allan Stephens's avatar
      tipc: Major redesign of broadcast link ACK/NACK algorithms · 7a54d4a9
      Allan Stephens authored
      
      
      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: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      7a54d4a9
    • Allan Stephens's avatar
      tipc: Ensure broadcast link re-acquires node after link failure · 93499313
      Allan Stephens authored
      
      
      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: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      93499313
  3. 30 Dec, 2011 1 commit
  4. 27 Dec, 2011 2 commits
  5. 18 Sep, 2011 1 commit
    • Allan Stephens's avatar
      tipc: Ensure both nodes recognize loss of contact between them · b4b56102
      Allan Stephens authored
      
      
      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: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      b4b56102
  6. 01 Sep, 2011 2 commits
    • Allan Stephens's avatar
      tipc: Prevent broadcast link stalling when another node fails · 169073db
      Allan Stephens authored
      
      
      Ensure that broadcast link messages that have not been acknowledged
      by a newly failed node do not get an implied acknowledgement until the
      failed node is removed from the broadcast link's map of reachable nodes.
      
      Previously, a race condition allowed a new broadcast link message to be
      sent after the implicit acknowledgement processing was completed, but
      before the map of reachable nodes was updated, resulting in the message
      having an expected acknowledgement count that required the failed node
      to explicitly acknowledge the message. Since this would never occur
      the new message would remain in the broadcast link's transmit queue
      forever, eventually causing the link to become congested and "stall".
      Delaying the implicit acknowledgement processing until after the update
      of the map of reachable nodes eliminates this race condition and prevents
      stalling.
      Signed-off-by: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      169073db
    • Allan Stephens's avatar
      tipc: Enhance cleanup of broadcast link when contact with node is lost · c5bd4d85
      Allan Stephens authored
      
      
      Enhances cleanup of broadcast link-related information when contact
      with a node is lost.
      
      1) All broadcast link-related cleanup now occurs only if the lost node
         was capable of communicating over the broadcast link.
      
      2) Following cleanup, the lost node is marked as no longer supporting
         the broadcast link, ensuring that any remaining broadcast messages
         received from that node prior to the re-establishment of a normal
         communication link are ignored.
      
      Thanks to Surya [Suryanarayana.Garlapati@emerson.com] for contributing
      a prototype version of this patch.
      Signed-off-by: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      c5bd4d85
  7. 13 Mar, 2011 10 commits
  8. 23 Feb, 2011 1 commit
    • Allan Stephens's avatar
      tipc: Combine bearer structure with tipc_bearer structure · 2d627b92
      Allan Stephens authored
      
      
      Combines two distinct structures containing information about a TIPC bearer
      into a single structure. The structures were previously kept separate so
      that public information about a bearer could be made available to plug-in
      media types using TIPC's native API, while the remaining information was
      kept private for use by TIPC itself. However, now that the native API has
      been removed there is no longer any need for this arrangement.
      
      Since one of the structures was already embedded within the other, the
      change largely involves replacing instances of "publ.foo" with "foo".
      The changes do not otherwise alter the operation of TIPC bearers.
      Signed-off-by: default avatarAllan Stephens <Allan.Stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      2d627b92
  9. 01 Jan, 2011 9 commits
  10. 02 Dec, 2010 2 commits
  11. 16 Oct, 2010 1 commit
  12. 13 Oct, 2010 1 commit
  13. 23 Sep, 2010 1 commit