NetWork Streams connection - reconnection trouble

[Greg_S.]

Hello all,

I use Network streams between few PCs to exchange data at high speed.

I have some issues sometimes to connect some streams (I use about 4 to 8 network streams some in both direction writing and reading).

The problem is that sometimes I have some issues connecting all streams, there is one or more that are not connected, one solution is to end those streams and restart the VI ( inside code there is a test if connected or not, and it tries to reconnect automaticaly but not working in this case).

Sometimes it is impossible to connect all the streams and have to restart labVIEW both side, and in some case even the computer.

The same problem can happened if all streams are connected and there is a disconnection (for example when I unplug ethernet cable and plug again), sometimes the reconnection is good for all, sometimes some cannot reconnect.

But when all are connected it is working so well.

Anybody has idea about this problem of connection ?

Thank You.

Greg

[Bob_Schor]

---

@Greg_S. wrote:

I have some issues sometimes to connect some streams (I use about 4 to 8 network streams some in both direction writing and reading).

---

As far as I know, a Network Stream is strictly in one direction, from Writer to Reader.  In my LabVIEW Real-Time code, I typically have a pair of Streams for exchanging "Messages" (that is to say, the Stream contents are the same TypeDef, basically sending similar data (and occasionally "echoing" the data) from Host to Target, or Target to Host).  

When you establish a N.S. Endpoint, you have to designate it as a Reader or a Writer.  Of course, once you've done that, you certainly can close the pair of Streams and re-constitute them as as Stream in the opposite direction, but this seems extremely complicated to me.

You did not, as you know, post your code showing how you are using Network Streams, but that's probably OK as a routine with 4 to 8 Network Streams is likely to be a challenge to review without you leading us through it.  But here is something you might try, a technique I've used to debug my Network Stream organization:

1. Set up a test system with "a few PCs to exchange data at high speed".
2. Write a simple "Test/Simulation" scenario where you send "easily-identified Data Packets" back and forth, trying to mimic the logic of your current situation, but sending sufficiently "known" packets that the receiver can signal if it gets a "wrong" Packet or fails to get a Packet (Time-Outs can be helpful here).
3. Log the traffic on each machine, and when you are done (hopefully with an Error), analyze the logs and try to see "what went wrong".  

I just noticed that (besides not showing any code) you didn't tell us anything about the system(s) on which you are running and sending Network Streams.  Are all of the "stations" PCs running Windows 10 and running some version of LabVIEW?  What Version?  32-bit or 64-bit LabVIEW?  Any machines running LabVIEW Real-Time?  PharLap or NI Linux Real-Time?  

Bob Schor

[Greg_S.]

Hi Bob,

To send code it will be a little complicated with sending all objects used inside. But I use nearly same as JKI network streams and like them bi-directional communication with reconnection.

I made a setup for testing : for my 4 days test (75Mbitd/sec exchange) it is working.

The fact is that sometimes I get problem to iniate the communication, sometimes some of streams do not connect.

From what you wrote 1. 2. 3. it was my test for 4 days, "unfortunately" no problem this time.

Aoll PCs are Windows 10, LabVIEW 2020 64 bits, no Real Time only windows PCs.

I wil look if I can made a zip for the code that contains all.

Thank you very much.

Greg

[Bob_Schor]

You might not need to send code.  I haven't looked at JKI's Network Stream stuff (I wrote my own routines, including describing how to set up Readers and Writers in a Post on the Forums almost a decade ago, unfortunately I've lost the link to it, but it got "Marked as a Solution", I think), but if you've been able to run 4 PCs exchanging data for 4 days, that strongly suggests to me that Network Streams are "doing the right thing", as long as the Network is not causing problems!

If you are on a "busy" network (as I assume is true at CNRS), there could well be conditions when "too many researchers spoil the TCP/IP Traffic".  You might not have a choice, but if you can connect all of your machines to a single (dedicated) switch that supports the data rate you need, your problems might disappear.

Bob Schor

[Greg_S. · Accepted solution]

It seems that is better as mentioned in White Paper to not write the IP both side.

So I did some test it works better with the IP write only one side of the Network Streams, but still some problem of connection. Less problem on disconnection.

All is done on private VLAN, but yes there is many data exchange ( about 75% of bandwith). The fact is that it seems that one of calculation we are doing can put down some of network streams but not all, it is this that for me is strange as we do not really how network streams are really build.

Thank you for your help.

[Bob_Schor]

---

@Greg_S. wrote:

It seems that is better as mentioned in White Paper to not write the IP both side.

So I did some test it works better with the IP write only one side of the Network Streams, but still some problem of connection. Less problem on disconnection.

All is done on private VLAN, but yes there is many data exchange ( about 75% of bandwith). The fact is that it seems that one of calculation we are doing can put down some of network streams but not all, it is this that for me is strange as we do not really how network streams are really build.

Thank you for your help.

---

I'm not sure which White Paper you read, but this one might be helpful.  I read its predecessor a decade ago, when I was starting to use Network Streams -- this one is similarly clear and thorough.

Bob Schor