Handling Events Across a Network

[paul_cardinale]

I am working on a large application that has multiple components, not necessarily all running on the same machine, communicating with each other across a network.  In some cases, a process will be waiting for some notification (e.g. a process is paused, waiting for a ‘continue’ signal).  I’d like this to be event driven rather than polled.  What is the best way to handle events across a network?

[paul.r]

How are the components on separate machines communicating with each other? What mechanism are you using to broadcast events between processes running on the same machine? 

Without any other information, I would have an application component that just listens to messages sent across the network, then broadcasts those events to components within that application in the same way you are doing inter process communication for non network components.

[BowenM]

I haven't used network streams for this exactly before, but you could theoretically use one exactly like a queue from across the network.  Have the data type a bundled command (string or enum) and variant for your data.  Leave the timeout on your reader set to -1 to prevent polling. 

[nathand]

I would generally use a TCP Read with a long timeout, even -1 (forever). If you need to stop before you receive the desired message, you close the TCP Refnum somewhere else in your code, which causes the TCP Read to exit with an error.

Depending on your network connection, UDP may be a better choice, if you're not worried about packet loss (if your components are all on the same switch it's highly unlikely you'll lose a packet).

Whenever you receive the message to continue, send a notification/enqueue something/generate a user event.

[Mark_Yedinak]

I have been using a Network Queue implementation for this type of thing. I originally downloaded it from LAVE but I believe I may have made some modifications to it over the years.

[paul_cardinale]

---

@paul.r wrote:

How are the components on separate machines communicating with each other? What mechanism are you using to broadcast events between processes running on the same machine? 

Without any other information, I would have an application component that just listens to messages sent across the network, then broadcasts those events to components within that application in the same way you are doing inter process communication for non network components.

---

The communication between components hasn't been designed yet.

I would like the mechanism to be the same regardless of whether the processes are on the same machine or different machines.

[paul.r]

Is there a reason you want to use the same communication method between components running on the same machine (and I am assuming running in the same LabVIEW application instance) and components running on another machine?

Personally, I think it is going to add a lot of unnecessary complexity to have all the application components talking to each other via TCP or something similar within the same application. I would have a network actor whose job is to do nothing but listen for messages to send across the network from the application, and receive messages across the network then broadcast them to the application, using some LabVIEW communication mechanism like a queue. So your network actor receives a message via TCP, then it sends it using a LabVIEW queue off for further processing. Similarly, it receives a message via a labVIEW queue, then just passes it along over the network. That way, most of your application components dont have to deal with networking code.

[Mark_Yedinak]

---

@paul.r wrote:

Is there a reason you want to use the same communication method between components running on the same machine (and I am assuming running in the same LabVIEW application instance) and components running on another machine?

Personally, I think it is going to add a lot of unnecessary complexity to have all the application components talking to each other via TCP or something similar within the same application. I would have a network actor whose job is to do nothing but listen for messages to send across the network from the application, and receive messages across the network then broadcast them to the application, using some LabVIEW communication mechanism like a queue. So your network actor receives a message via TCP, then it sends it using a LabVIEW queue off for further processing. Similarly, it receives a message via a labVIEW queue, then just passes it along over the network. That way, most of your application components dont have to deal with networking code.

---

The network queue I posted above uses both standard LabVIEW queues and TCP connections. If a LabVIEW queue exists with the name provided it will use that and not use a TCP connection. The nice thing about that set of VIs is that it functions exactly like a standard LabVIEW queue but it works across applications and computers. This library is the foundation of a rather complex and robust messaging system we have been using for years.

[drjdpowell]

---

paul_cardinale wrote:

The communication between components hasn't been designed yet.

I would like the mechanism to be the same regardless of whether the processes are on the same machine or different machines.

---

If you'd like to look at what I use, it is in Messenger Library.  Have a look at the TCP examples included.   It uses text-variant messages and a TCP client-server implementation that seamlessly interoperates with the local communication methods (which can be Queue or User-Event based).  Supports messaging patterns like Request-Reply and Register-Notify seamlessly across TCP also. 

There are some instructional videos on Youtube; have a look at "Messenger Library and TCP".  I haven't been able to personally use the TCP components as much as I'd like too, but "bbean" on LAVA has been using it in anger, and has helped to battle-test and improve it.