OpenLCB Note: On Software Structure

Much of OpenLCB is based on broadcast messaging: A request for information is sent, received by all nodes, and perhaps some of them will reply. The protocol provides no concrete way to know when the last answer has been received.

Software that works with this system should keep track of everything that it hears, maintaining an internal model of the state of the parts of the OpenLCB that it's interested in. As messages come in, that model is then updated so that it's always as up-to-date as possible. The OpenLCB protocols help this by broadcasting status information as nodes become active, are reconfigured, etc. When a node or program joins the network, it can send requests for the information it needs to track. It then receives the direct responses to build an initial model, plus additional messages later on to keep the model up to date.

A model-based approach works much better than an “inquire when you need to know” approach. If the program waits until the last possible moment to request information that it needs, it'll still have to wait for the replies, and it won't reliably know when the last reply arrives. It will still need to build a model based on the replies, but now it will be much harder to ensure that model is complete. Sending lots of un-needed broadcast requests, along with the associated replies, can result in significant load on the network and nodes.


Site hosted by

This is SVN $Revision: 721 $