Detect a NodeID collision (as opposed to alias collision)

[Poikilos]

This is would cause #92 to recur (both nodes keep trying to redo the reservation process forever, causing the openlcb network stack to become unusable).

• This is apparently undefined behavior in the Standard: It just says to make them unique, not what to do if they aren't (?)
  • How do detect this during alias reservation isn't clear (to me). Alias reservation loop occurs when two instances are open #92 isn't resolved by implementing the Standard's alias reservation process (It is mitigated by generating a unique NodeID) because the issue occurs based on a duplicate NodeID not duplicate alias.

If a NodeID collision is detected, the solution would be to:

• :edit: Go offline (see comment)
  • Clear nodeIdToAlias and aliasToNodeID (as a part of going offline), except potentially keep it somewhere for:
    • Make an improved increment method (replacing generate_node_id_str) that checks the alias map and skips any used NodeID (It would have to detect if there is an increment loop--rare, as described elsewhere in this issue--see id_range_prefix note below).
• increment the NodeID. This could be done using my function: generate_node_id_str(increment=True). The increment option would cause it to be incremented rather than relying on a hash of IP Address + process ID.

Extremely rare except:

• If user specifies a local NodeID manually rather than using generate_node_id_str.
• More likely if fewer than last three octets at the end are generated (Using id_range_prefix with more than 3 octets).
• If there is a rollover of generate_node_id_str due to many calls over time and never closing the program, especially if there is a large number of virtual nodes, and/or they are deleted and re-created multiple times before closing the program.

Related issues:

• Generate unique local NodeID #78

[bobjacobsen]

See section 3.5.4 of the Message Transport Standard and section 2.3.5.4 of the Message Transport TN for the general case. See also section 6.2.6 of the CAN Frame Transfer S and 2.6.2.6 of the CAN Frame Transfer TN

Bottom line, changing the Node ID is not OK. If two nodes share a Node ID, one or both should go offline.