Skip to content
  • Jon Paul Maloy's avatar
    tipc: introduce node contact FSM · 1a20cc25
    Jon Paul Maloy authored
    
    
    The logics for determining when a node is permitted to establish
    and maintain contact with its peer node becomes non-trivial in the
    presence of multiple parallel links that may come and go independently.
    
    A known failure scenario is that one endpoint registers both its links
    to the peer lost, cleans up it binding table, and prepares for a table
    update once contact is re-establihed, while the other endpoint may
    see its links reset and re-established one by one, hence seeing
    no need to re-synchronize the binding table. To avoid this, a node
    must not allow re-establishing contact until it has confirmation that
    even the peer has lost both links.
    
    Currently, the mechanism for handling this consists of setting and
    resetting two state flags from different locations in the code. This
    solution is hard to understand and maintain. A closer analysis even
    reveals that it is not completely safe.
    
    In this commit we do instead introduce an FSM that keeps track of
    the conditions for when the node can establish and maintain links.
    It has six states and four events, and is strictly based on explicit
    knowledge about the own node's and the peer node's contact states.
    Only events leading to state change are shown as edges in the figure
    below.
    
                                 +--------------+
                                 | SELF_UP/     |
               +---------------->| PEER_COMING  |-----------------+
        SELF_  |                 +--------------+                 |PEER_
        ESTBL_ |                        |                         |ESTBL_
        CONTACT|      SELF_LOST_CONTACT |                         |CONTACT
               |                        v                         |
               |                 +--------------+                 |
               |      PEER_      | SELF_DOWN/   |     SELF_       |
               |      LOST_   +--| PEER_LEAVING |<--+ LOST_       v
    +-------------+   CONTACT |  +--------------+   | CONTACT  +-----------+
    | SELF_DOWN/  |<----------+                     +----------| SELF_UP/  |
    | PEER_DOWN   |<----------+                     +----------| PEER_UP   |
    +-------------+   SELF_   |  +--------------+   | PEER_    +-----------+
               |      LOST_   +--| SELF_LEAVING/|<--+ LOST_       A
               |      CONTACT    | PEER_DOWN    |     CONTACT     |
               |                 +--------------+                 |
               |                         A                        |
        PEER_  |       PEER_LOST_CONTACT |                        |SELF_
        ESTBL_ |                         |                        |ESTBL_
        CONTACT|                 +--------------+                 |CONTACT
               +---------------->| PEER_UP/     |-----------------+
                                 | SELF_COMING  |
                                 +--------------+
    
    Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
    Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    1a20cc25