Duplicate ID handling at message level

[bobjacobsen]

The Message Network Standard section 3.5.4 says in its entirety:

OpenLCB nodes shall indicate an error when they detect an incoming message with a Source Node ID equal to their own using whatever indication technology is available. See the General Event documentation for one method of indication that uses a well-known Global-Event.

The TN has some additional discussion in section 2.3.5.4. The relevant part:

If possible, it should emit a Producer-Consumer Event (PCER) message with the “Duplicate Source ID detected” global event, which carries the duplicate node ID in the Source Node ID field. After sending the “Duplicate Source ID detected” global event, the node should not transmit any further “Duplicate Source ID detected” messages until reset because this message will be received at the other duplicate-ID node(s), resulting in additional “Duplicate Source ID detected” global events and causing a possible message loop. Optionally, it could allow (sic) to send again after e.g. 5 seconds.

(The references to a "global event" should be changed to "well-known event")

Should we move the part about not resending the well-known event to the Standard? This seems critical to proper operation of this error handling.

This is admittedly handling a rare case. Nodes don't often have the same ID, and CAN nodes will handle this at the frame level if they do (see section 6.2.6 of the Frame Transfer Standard). But someday we'll have transport beyond CAN frames, e.g. native TCP, and we might want to clean this up before then.

[JimKueneman]

I think it should be in the spec I think. The specs are to ensure a node does not degrade the network and have an infinite loop sending usless messages as fast as it can would qualify as degrading the network.