Re-entrant VIs and network streams

[xl600]

Can the network stream writer exist within a re-entrant VI and write arrays or strings to the same endpoint from multiple threads?

I have a series of VIs which produce data (Flattened to strings) which I would like to send to my host PC via a single network stream.  Basically, the data is just a Channel Number combined with a waveform (Of varying data types).  These are produced from multiple VIs which run asynchronously from each other.

What I'd like to see at the reader is a continuous stream of strings, each representing a flattened cluster in the same order they were written.

Thanks,

XL600

[natasftw]

http://www.ni.com/white-paper/12267/en/#toc4

[xl600]

I've read through that white paper and wasn't able to gleen from it whether or not the network stream writer was thread safe such that two VIs can write to the same endpoint without conflicting.

[PatrickLye]

I can't imagine this will work. You need matching endpoints. This is a one way communication path as described in the file in the link above. When you lose one endpoint you have to close the other and recreate to get communications.

[xl600]

I was thinking I would only create the endpoint in one VI, but have writers in multiple VIs using the same endpoint name.

It's sounding like this isn't a recommended approach so I can add a string queue to hold the elements from the multiple sources, then use a single loop to write to the stream (By flushing the queue into the stream periodically).

[Bob_Schor · Accepted solution]

My main RT Project uses 4 Network Streams -- two form a bidirectional Message (as in Queued Message Handler) stream, one sends sampled data (from a single point) to the Host, and the other sends "Event" data, which includes digital I/O level changes, Action Engine transitions, sending and receiving Messages on the Message Streams, etc.  There is a single Event "Sender", fed by a Queue that everyone who needs to send an Event dumps the Event into -- the Event Streamer is basically the Consumer of this Producer/Consumer pattern, sending each Event to the Host as it is dequeued from whatever routine in the RT Target generated it.  This sounds a lot like that you have decided to try -- I can recommend it, as it works well for me.

Bob Schor

[xl600]

Thanks.  That helps to validate the approach.

[natasftw]

"Network streams were designed for lossless, point-to-point communication.  While this works well for data streaming and command based applications, it makes establishing arbitrary N:1 or many to many communication paths very difficult.  This is a requirement that is common for many client/server applications." This was in the section I linked.

Using a queue as Bob suggested can help you get around this.  But, Network Streams aren't mean to have N:1 or 1:N configurations.  You'd have to handle that logic in addition to the Network Streams