• Jon Maloy's avatar
    tipc: handle collisions of 32-bit node address hash values · 25b0b9c4
    Jon Maloy authored
    When a 32-bit node address is generated from a 128-bit identifier,
    there is a risk of collisions which must be discovered and handled.
    
    We do this as follows:
    - We don't apply the generated address immediately to the node, but do
      instead initiate a 1 sec trial period to allow other cluster members
      to discover and handle such collisions.
    
    - During the trial period the node periodically sends out a new type
      of message, DSC_TRIAL_MSG, using broadcast or emulated broadcast,
      to all the other nodes in the cluster.
    
    - When a node is receiving such a message, it must check that the
      presented 32-bit identifier either is unused, or was used by the very
      same peer in a previous session. In both cases it accepts the request
      by not responding to it.
    
    - If it finds that the same node has been up before using a different
      address, it responds with a DSC_TRIAL_FAIL_MSG containing that
      address.
    
    - If it finds that the address has already been taken by some other
      node, it generates a new, unused address and returns it to the
      requester.
    
    - During the trial period the requesting node must always be prepared
      to accept a failure message, i.e., a message where a peer suggests a
      different (or equal)  address to the one tried. In those cases it
      must apply the suggested value as trial address and restart the trial
      period.
    
    This algorithm ensures that in the vast majority of cases a node will
    have the same address before and after a reboot. If a legacy user
    configures the address explicitly, there will be no trial period and
    messages, so this protocol addition is completely backwards compatible.
    Acked-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>
    25b0b9c4
link.c 57.2 KB