1. 16 Feb, 2012 5 commits
  2. 13 Feb, 2012 4 commits
  3. 07 Feb, 2012 17 commits
  4. 06 Feb, 2012 14 commits
    • Allan Stephens's avatar
      tipc: Minor optimization to rejection of connection-based messages · dff10e9e
      Allan Stephens authored
      Modifies message rejection logic so that TIPC doesn't attempt to
      send a FIN message to the rejecting port if it is known in advance
      that there is no such message because the rejecting port doesn't exist.
      Signed-off-by: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      dff10e9e
    • Allan Stephens's avatar
      tipc: Eliminate alteration of publication key during name table purging · 3175bd9a
      Allan Stephens authored
      Removes code that alters the publication key of a name table entry
      that is being forcibly purged from TIPC's name table after contact
      with the publishing node has been lost.
      
      Current TIPC ensures that all defunct names are purged before
      re-establishing contact with a failed node.  There used to be a risk
      that the publication might be accidentally deleted because it might be
      re-added to the name table before the purge operation was completed.
      But now there is no longer a need to ensure that the new key is different
      than the old one.
      Signed-off-by: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      3175bd9a
    • Allan Stephens's avatar
      tipc: Prevent loss of fragmented messages over broadcast link · 63e7f1ac
      Allan Stephens authored
      Modifies broadcast link so that an incoming fragmented message is not
      lost if reassembly cannot begin because there currently is no buffer
      big enough to hold the entire reassembled message. The broadcast link
      now ignores the first fragment completely, which causes the sending node
      to retransmit the first fragment so that reassembly can be re-attempted.
      
      Previously, the sender would have had no reason to retransmit the 1st
      fragment, so we would never have a chance to re-try the allocation.
      
      To do this cleanly without duplicaton, a new bclink_accept_pkt()
      function is introduced.
      Signed-off-by: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      63e7f1ac
    • Allan Stephens's avatar
      tipc: Prevent loss of fragmented messages over unicast links · b76b27ca
      Allan Stephens authored
      Modifies unicast link endpoint logic so an incoming fragmented message
      is not lost if reassembly cannot begin because there is no buffer big
      enough to hold the entire reassembled message. The link endpoint now
      ignores the first fragment completely, which causes the sending node to
      retransmit the first fragment so that reassembly can be re-attempted.
      
      Previously, the sender would have had no reason to retransmit the 1st
      fragment, so we would never have a chance to re-try the allocation.
      Signed-off-by: default avatarAllan Stephens <allan.stephens@windriver.com>
      b76b27ca
    • 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: Add missing locks in broadcast link statistics accumulation · b98158e3
      Allan Stephens authored
      Ensures that all attempts to update broadcast link statistics are done
      only while holding the lock that protects the link's main data structures,
      to prevent interference by simultaneous updates caused by messages
      arriving on other interfaces.
      Signed-off-by: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      b98158e3
    • Allan Stephens's avatar
      tipc: Fix bug in broadcast link duplicate message statistics · 0232c5a5
      Allan Stephens authored
      Modifies broadcast link so that it increments the "received duplicate
      message" count if an incoming message cannot be added to the deferred
      message queue because it is already present in the queue. (The aligns
      broadcast link behavior with that of TIPC's unicast links.)
      Signed-off-by: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      0232c5a5
    • Allan Stephens's avatar
      tipc: Fix node lock reclamation issues in broadcast link reception · 8a275a6a
      Allan Stephens authored
      Fixes a pair of problems in broadcast link message reception code
      relating to the reclamation of the node lock after consuming an
      in-sequence message.
      
      1) Now retests to see if the sending node is still up after reclaiming
         the node lock, and bails out if it is non-operational.
      
      2) Now manipulates the node's deferred message queue only after
         reclaiming the node lock, rather than using queue head pointer
         information that was cached previously.
      Signed-off-by: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      8a275a6a
    • Allan Stephens's avatar
      tipc: Add missing broadcast link lock when sending NACK · 57732560
      Allan Stephens authored
      Ensures that any attempt to send a NACK message over TIPC's broadcast
      link has exclusive access to the link's main data structures, to prevent
      interference with a simultaneous attempt to send other broadcast link
      traffic (such as application-generated multicast messages).
      Signed-off-by: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      57732560
    • Allan Stephens's avatar
      tipc: Fix problem with broadcast link synchronization between nodes · 47361c87
      Allan Stephens authored
      Corrects a problem in which a link endpoint that activates as the
      result of receiving a RESET/STATE sequence of link protocol messages
      fails to properly record the broadcast link status information about
      the node to which it is now communicating with. (The problem does
      not occur with the more common RESET/ACTIVATE sequence of messages.)
      The fix ensures that the broadcast link status info is updated after
      the RESET message resets the link endpoint, rather than before, thereby
      preventing new information from being overwritten by the reset operation.
      Signed-off-by: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      47361c87
    • 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
    • Allan Stephens's avatar
      tipc: Prevent broadcast link stalling in dual LAN environments · 4d75313c
      Allan Stephens authored
      Ensure that sequence number information about incoming broadcast link
      messages is initialized only by the activation of the first link to a
      given cluster node.  Previously, a race condition allowed reset and/or
      activation messages for a second link to re-initialize this sequence
      number information with obsolete values. This could trigger TIPC to
      request the retransmission of previously acknowledged broadcast link
      messages from that node, resulting in broadcast link processing becoming
      stalled if the node had already released one or more of those messages
      and was unable to perform the required retransmission.
      
      Thanks to Laser <gotolaser@gmail.com> for identifying this problem
      and assisting in the development of this fix.
      Signed-off-by: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      4d75313c
    • Allan Stephens's avatar
      tipc: Prevent transmission of outdated link protocol messages · 92d2c905
      Allan Stephens authored
      Ensures that a link endpoint discards any previously deferred link
      protocol message whenever it attempts to send a new one.
      
      Previously, it was possible for a link protocol message that was unsent
      due to congestion to be transmitted after newer protocol messages had
      been sent. The stale link protocol message might then cause the receiving
      link endpoint to malfunction because of its outdated conent.
      
      Thanks to Osamu Kaminuma [okaminum@avaya.com] for diagnosing the problem
      and contributing a prototype patch.
      Signed-off-by: default avatarAllan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      92d2c905