Use Case of Publish/Subscribe in LabVIEW
- If you use some parallel loops in your program
- If you want to send messages from one loop to each other loop(-s)
- If your project is large you can see each message, which is send from one loop to other
- If you want to reduce/improve the message traffic between loops, this pattern will help you to filter messages. So a message will be sent ONLY to interested loops
- If you use dynamical parallel loops in your projects
- If you use synchronisation tools and user events to communicate between parallel loops
- If you want to communicate between applications on one or different PCs over Ethernet/Internet
- If you want to create an software interface to applications written in other programming languages
- If you want to debug your application remotely
The best example is a live chat like ICQ, where all clients communicates over www. Each client registers dynamically and receives messages from other clients.A other example is if you have to show/log some data from unknown count of devices and send commands to one or more selected devices.
Background
Since I started to use parallel loops in my programs I always try to get out a perfect and universal pattern, which I can use in all my middle and large projects.
In my first LabVIEW project I have had only one VI with a very big block diagram. I used three or four loops and communicated over local variables.
In the next project I divided my main VI into subVIs and communicated using global variables. My block diagrams became smaller, but I have still some problems with race conditions. To avoid race conditions I used some boolean flags shift registers and so on. But I am sure, that this program have certain bugs.
Next project was better because I discovered the synchronisation palette! Of course queues, notifiers and user events are the best choice for communication between parallel loops. No problems with race conditions, no data losing in queues, no problems with CPU usage and timing.
One thing I discover some later - User Events. User events give you almost the same advantages like queues, but you can notify more than one loop (all registered event structures) using one user event.
Of course I use almost all of tools from synchronisation palette + user events in my projects, but all of them have it's advantages/disadvantages and it’s right.
Current design pattern I use
It’s not to complex. I have a cluster with three arrays of refnums:
aQueue
aNotifier
aUserEvent
All queues/notifiers/user events will be created on the beginn of my main VI and closed on the end of the main VI. Each loop gets thie whole cluster with all available refnums.
And I use three enum-typedefs where the names of my queue/notifier or user event loops are listed. If I want to send a message from one to a other loop, so I select the right array from cluster and select then the right receiver loop using the relevant enum-typedef.
But this pattern works only in statically called Vis, because I have to know at the start of my main VI which parallel VI which communication type and which name (for my enums and for creating the refnum).
But if I don’t know how many loops/applications/clients/tasks/threads my application have to handle, so I need a pattern which works dynamically.
Kinds of Publish/Subscribe
Topic based
Each client creates it’s own Queue/Notifier/User Event and sends to the dispatcher his reference. The dispatcher(core) adds this reference to a clients array. So in the next step client subscribes/subscribes topics/channels which it wants to receive from other registered clients. So if a client sends a message to the dispatcher, it will look which clients are interested (subscribers) on this message and will send this message to this clients.
Broadcast based
A client sends a message to the dispatcher. The dispatcher looks splits this message in message name and message content. Than it sends the message name (not the content) to all clients. The service task of the client receives this and ansvers to the dispatcher if the client is interested in the message content or not. So the dispatcher sends the content to all interested clients after receiving of all answers.
Content based
„Both Broadcast-Based Publish/Subscribe implementations and List-Based Publish/Subscribe implementations can be broadly categorized as topic-based because they both use predefined subjects as many-to-many channels. Publish/Subscribe implementations have recently evolved to include a new form—Content-Based Publish/Subscribe. The difference between topic-based and content-based approaches is as follows:
In a topic-based system, processes exchange information through a set of predefined subjects (topics) which represent many-to-many distinct (and fixed) logical channels. Content-based systems are more flexible as subscriptions are related to specific information content and, therefore, each combination of information items can actually be seen as a single dynamic logical channel. This exponential enlargement of potential logical channels has changed the way to implement a pub/sub system. [Baldoni03]
The practical implication of this approach is that messages are intelligently routed to their final destination based on the content of the message. This approach overcomes the limitation of a broadcast-based system, where distribution is coupled to a multicast tree that is based on Transmission Control Protocol (TCP). It also gives the integration architect a great deal of flexibility when deciding on content-based routing logic.“
[http://msdn.microsoft.com/en-us/library/ms978603.aspx]
I understand it good, but I am not ready to use/explain this further more.
My wish is to realize the topic based pattern in LabVIEW!
Already made
The first implementation which is very successful you will find here:
It works very good, and I used it in two of my projects and as demonstration I made a live web chat in LabVIEW, which works fine too.
But of course it is not easy to implement without to know how it works and what is the background of the use case.
Now I want to improve this pattern using LVOOP and make easy to understand interface, so everybody can use it in his projects.
More common information
| Comments |
|
