This is my realisation of topic based Publish/Subscribe Software Design Pattern.
http://en.wikipedia.org/wiki/Publish/subscribe
http://en.wikipedia.org/wiki/Observer_pattern
The dispatcher is the main task of this pattern, which administrates a topic table. If any (Queue- Notifier- User Event- and TCP/IP based) client starts, it should register himself by the dispatcher, so the dispatcher adds them into the topic table. The next step the client should do - is to subscribe to topics. If the dispatcher receives a message from any client, it looks which clients want to receive this message and send it only to this clients. So you can rediuce some data traffic in your programm. If a client is no more interested in a topic, it can unsubscribe from this topic. If a client want to be removed from the table, it should unregister.
So you can dynamically start/stop clients and realize a software, which is plugin able.
Supporting TCP/IP protocoll gives you a chance to communicate between programm modules, different applications, and different computers over network. Therefore you can connect two or more dispatchers and select topics, which you want to send or receive. This feature gives you a big advantage - remote debugging.
Publish Subscriber
-
Eugen Graf
- guru
- Сообщения: 6502
- Зарегистрирован: 13 ноя 2007, 02:20
- Награды: 4
- Версия LabVIEW: 2009
- Откуда: Saarbrücken
- Контактная информация:
-
Eugen Graf
- guru
- Сообщения: 6502
- Зарегистрирован: 13 ноя 2007, 02:20
- Награды: 4
- Версия LabVIEW: 2009
- Откуда: Saarbrücken
- Контактная информация:
Re: Publish Subscriber
More explanations:
turbot, you can read more about here
http://forums.lavag.org/publish-subscriber-t7793.html
or ask me what do you want to know about this pattern.
If you have paralell loops in your programm, they should communicate. For communication you can select following:
local variable
global variable
notifier
queue
user event
tcp/ip
...
I implemented in this pattern 4 last communication types, because I don't like any variables.
So the dispatcher have the task to dispatch incomming (over one dispatcher queue) messages to loops interested in. So the dispatcher is the main VI and should be started as first. In the dispatcher you will find a table. Row headers are loop names, column headers are message names and in the table you will see the communication type (one of 4 implemented) of the loop.
If if the dispatcher is started, you can begin to start your tasks (parallel loops). At the start of one task, this task have to say to the dispatcher it's name, it's reference, it's type of communication and which messages it want do receive from the dispatcher. The dispatcher will add this informations into the table. So if any task will send a message to the dispatcher, it look in the table which tasks are interested in this message and will send the message to the interested tasks. All the communication should go over the dispatcher, so it's much easier to debug your programm, because you have all informations about all tasks in your programm on one place. And not only, all messages go over the dispatcher, so you can spy every message from every task, and YOU CAN DO IT REMOTELY from an other PC, because TCP/IP is implemented too.
turbot, you can read more about here
http://forums.lavag.org/publish-subscriber-t7793.html
or ask me what do you want to know about this pattern.
If you have paralell loops in your programm, they should communicate. For communication you can select following:
local variable
global variable
notifier
queue
user event
tcp/ip
...
I implemented in this pattern 4 last communication types, because I don't like any variables.
So the dispatcher have the task to dispatch incomming (over one dispatcher queue) messages to loops interested in. So the dispatcher is the main VI and should be started as first. In the dispatcher you will find a table. Row headers are loop names, column headers are message names and in the table you will see the communication type (one of 4 implemented) of the loop.
If if the dispatcher is started, you can begin to start your tasks (parallel loops). At the start of one task, this task have to say to the dispatcher it's name, it's reference, it's type of communication and which messages it want do receive from the dispatcher. The dispatcher will add this informations into the table. So if any task will send a message to the dispatcher, it look in the table which tasks are interested in this message and will send the message to the interested tasks. All the communication should go over the dispatcher, so it's much easier to debug your programm, because you have all informations about all tasks in your programm on one place. And not only, all messages go over the dispatcher, so you can spy every message from every task, and YOU CAN DO IT REMOTELY from an other PC, because TCP/IP is implemented too.
-
Eugen Graf
- guru
- Сообщения: 6502
- Зарегистрирован: 13 ноя 2007, 02:20
- Награды: 4
- Версия LabVIEW: 2009
- Откуда: Saarbrücken
- Контактная информация:
Re: Publish Subscriber
I will start to remake this pattern using OOP. If there are interested people, so answer.
Re: Publish Subscriber
Hi Eugen,
Very glad to receive your email.
The hangup I met last time was caused by the data loop. I should not select same topic in local and remote topic in PubSub_ConnectAsClient.vi at same time.
One thing may need to improve is the local and remote topic list in PubSub_ConnectAsClient.vi should be updated when new client is connected or new subscription is made.
Regards,
Yu Ming
Very glad to receive your email.
The hangup I met last time was caused by the data loop. I should not select same topic in local and remote topic in PubSub_ConnectAsClient.vi at same time.
One thing may need to improve is the local and remote topic list in PubSub_ConnectAsClient.vi should be updated when new client is connected or new subscription is made.
Regards,
Yu Ming
-
Eugen Graf
- guru
- Сообщения: 6502
- Зарегистрирован: 13 ноя 2007, 02:20
- Награды: 4
- Версия LabVIEW: 2009
- Откуда: Saarbrücken
- Контактная информация:
Re: Publish Subscriber
Yes, that is right.turbot писал(а): The hangup I met last time was caused by the data loop. I should not select same topic in local and remote topic in PubSub_ConnectAsClient.vi at same time.
Can you explain me what you want to do using this pattern. I think you can solve it on the other way, may be without to connect two or more dispatchers remotely.
Good ideaturbot писал(а): One thing may need to improve is the local and remote topic list in PubSub_ConnectAsClient.vi should be updated when new client is connected or new subscription is made.
Re: Publish Subscriber
What I tried to do is a message system. If any one generate a message or alarm, it need to transfer to all the rest ones. If one of them acknowledge or make an action on the message, the others also need to know it. Also with some data transmission, command and status and transmission.
-
Eugen Graf
- guru
- Сообщения: 6502
- Зарегистрирован: 13 ноя 2007, 02:20
- Награды: 4
- Версия LabVIEW: 2009
- Откуда: Saarbrücken
- Контактная информация:
Re: Publish Subscriber
For this issue you need to start one dispatcher on one PC and on other PCs you can start any TCP/IP clients.
That should work without any problems, try it.
That should work without any problems, try it.
Re: Publish Subscriber
I am trying to do the below:
"One thing may need to improve is the local and remote topic list in PubSub_ConnectAsClient.vi should be updated when new client is connected or new subscription is made."
May you give any suggestion about it?
What I plan to do is when a new subscribtion is made in the case of subscribe in dispatch vi, it will trigger the PubSub_ConnectAsClient.vi to update the local topic list. Also trigger the any connected remote client to update their remote topic list.
Can this be down just using a update topic or change the code inside?
Thanks.
Turbot
"One thing may need to improve is the local and remote topic list in PubSub_ConnectAsClient.vi should be updated when new client is connected or new subscription is made."
May you give any suggestion about it?
What I plan to do is when a new subscribtion is made in the case of subscribe in dispatch vi, it will trigger the PubSub_ConnectAsClient.vi to update the local topic list. Also trigger the any connected remote client to update their remote topic list.
Can this be down just using a update topic or change the code inside?
Thanks.
Turbot
-
maxgod145
- user
- Сообщения: 87
- Зарегистрирован: 28 окт 2008, 20:40
- Награды: 1
- Версия LabVIEW: 8,5;8.6
- Откуда: Киев
- Контактная информация:
Re: Publish Subscriber
Hi people!I need all what you know about network icq!I'll be thanks for all info!!