Register for Events / Broadcast Best Practices

[Masony]

If there are articles or another post that is asking / answering my question, please point me to those resources as I most likely have overlooked them when doing my research.

I've been working on learning DQMH and using it on a few projects and as I've used it, I've been curious what the Best Practices would be regarding how to design a project specifically with how and where module broadcasts go. Below are two articles that I have been referencing and they've been incredibly useful, but to me at least, seem to offer differing advice but I'm probably just interpreting them incorrectly.

https://delacor.com/simple-dqmh-dos-and-donts/

http://delacor.com/tips-and-tricks-for-a-successful-dqmh-based-project/

Below two diagrams each from the articles above regarding project design / layout

• the tree method (similar to actor framework)

• and (I'm not sure what to call) this method

How I'm interpreting these are if you design your project to follow the tree or actor tree method, then you have a singular module or VI that starts modules which in turn can start their own modules. The drawback is if you need to send data up or down the tree then there are extra broadcasts / requests that needed to be added to modules that are simply passing the data on without needing it. This adds extra VIs that potentially don't need to be used if the module is used in another project. It also adds time, granted the Delacor scripting tools help immensely with that.

How I see the second method is each module can be subscribed to any other module's broadcasts allowing you to skip broadcasting data up the tree through modules that don't need the data. You could also send requests to any other module without having to travel up and down the tree. The downside I see in this is that depending on the project size this could become quite difficult to manage where a module is receiving data and what it is doing with it (although maybe my documentation is just really poor) as well as potentially having modules too tightly coupled to one another (again there are articles discussing how to limit or eliminate this). It is easier to manage how data is traveling throughout a project if you stick to the tree method for me at least.

Is this just a matter of preference as to which method one should use in a project? Are there performance or other reasons why one method should be used over another? Again, I'm just learning DQMH so maybe this has been answered somewhere else or I'm just looking at project design wrong as a whole and these methods are the same.

Thanks for the help!

[Taggart]

Don't take the CML diagram too seriously. If you listen to Fab talk that is meant as an understandable and familiar example for beginners and tries to follow the layout of the NI CML. It is not meant as an example of best practices.

You do want to be very careful about how you route messages. You want to be very cognizant of coupling and dependencies. The best way to manage that is the tree structure. So it helps with dependencies. It also helps with debugging. A lot less messages flying around. When you have a system where every module talks to every module, the complexity skyrockets. Just count the number of connections. You also introduce the possibility for circular dependencies and circular messaging loops and deadlocks.

As to the having to add messages as things percolate up or down the tree, that is slightly more work, but that is not a bug, that is a feature. Ie. as you move up the tree you are changing context. You are getting farther away from the low-level hardware and functions and into the domain logic. The meaning of things should change as you move up and down the tree and you should be translating things. If you are not, you probably need to work improving your modeling and separating out the domain logic from the low-level logic.

That said, if you want  a compromise between the 2, I would keep requests following the tree structure and allow broadcasts to go anywhere. That is a pretty good compromise that helps avoid the circular dependency issue and keeps tracking messages for debugging pretty easy. Dr Powell had a good presentation at GDevCon #1 about this. Data versus commands. Commands flow down the actor tree. Data generally flows up the tree, but with data you can short circuit the tree without causing too many problems. If you do that with commands you will get into trouble very quickly.

https://youtu.be/HIuzY_Bs7BI

As far as dependency management, checkout this video.

https://youtu.be/_YcfT-Ec0ws

[Masony]

That makes sense, from what I've read and the videos I've watched it just felt like using the CML diagram as the way the broadcasts and requests are literally laid out wasn't the best way to go but definitely helps when designing a project from the beginning. I just wasn't sure if I was missing something as creating a "pass-through" broadcast felt wasteful, but you make a good point that this could be because of some inefficiencies in my project design.

I appreciate your comments and the links, I will be checking them out. 

[Taggart]

It's all a process. The CML example works as is, there's just "better" ways to do it.

[ChrisFarmerWIS]

My advice on top of Sam's thorough response, is to not have too many layers in the tree.

For simple applications, you shouldn't need more than 2 layers.  For more advanced applications, a 3rd layer might be necessary.

We've done 4 layers in the past and it was confusing, and difficult to debug, and too many messages being passed through a module to get to another.

And I second Sam's comment about multiple broadcast listeners.  We often have a lower level module (ie a database, or a device driver), that might need to broadcast status or data to one or more higher level modules.  This is ok in our book too.

[Taggart]

yes Chris, shallow and wide is generally better.

[joerg.hampel]

One more thing is to register dynamically for other modules' events, i.e. forwarding the broadcast event refnum of a "child" module up the tree to a common ancestor and then back down to the receiving "child". That way, you can implement child-to-child communication without static linking between them. 

While we're not doing that all the time, it's good to know about that possibility.

[Masony]

That is a pretty interesting idea, would you be able to provide an article or point me towards an example that makes use of that?