openlcb / documents

The OpenLCB specification: standards, recommended practices and other documentation.
3 stars 7 forks source link

Limiting Event Identified messages at start up to those in use #77

Open dpharris opened 1 year ago

dpharris commented 1 year ago

Nodes can have a lot of eventids, and they are required to report them at start up with Consumer_Identified and Producer_Identified messages. This can be a significant amount of traffic on start up.

This can be mitigated by using Consumer_Range_Identified and Producer_Identified messages, but this loses the utility of reporting the validity of the eventids inherent in the other Identified messages.

Should we require, or recommend, that nodes should only report eventids being in use?

This may or may not be possible, in general. However, foreign-events, ie those not in the node's normal range can likely be assumed to be active. In addition, node's often have logic indicating the use of an eventid, for example, the Tower LCC consumer-events have the option of 'None' for their action, and can be assumed not to be active for that line.

This may need to be 'best effort', and so a recommendation. Even so, start up traffic can likely be reduced.

bobjacobsen commented 1 year ago

What would the language for this look like?

Right now, the Standard says:

Upon receipt of either an unaddressed (global) Identify Events message or an addressed Identify Events message addressed to the node, that node shall reply with Producer Identified and/or Producer Range Identified messages covering all non-automatically-routed Event IDs produced by the node, and Consumer Identified and/or Consumer Range Identified messages covering all non-automatically- routed Event IDs consumed by the node.

Perhaps the TN should say something like

The Standard refers to produced by and consumed by and we really mean it. If the node as currently configured won't produce or consume a specific event ID, a corresponding 'Identified' message should not be sent. This will prevent un-necessary traffic, which in some cases could be very large.