LabVIEW loses data connection to remote application intermittently

[habeebsiddique]

Hi All, 

I am running a LabVIEW application on my computer IP:172.16.144.1 that collects data from another computer on IP: 172.16.144.2, port :8089.

But intermittently it has been giving communication break ups.

I did a netstat -anobq on command terminal. 

I found that my LabVIEW application is using numerous ports to try and connect with  port 8089 on computer with IP: 172.16.144.2, and putting each port in TIME_WAIT state.

i read that the numerous TIME_WAIT states are symptoms of Port Exhaustion problems. Below is a link.

https://docs.microsoft.com/en-us/archive/blogs/askds/port-exhaustion-and-you-or-why-the-netstat-tool...

I am not able understand why my LabVIEW application is doing this. Any pointers to what I should be looking in.

Attached is my text file on the netstat output.

Any help is much appreciated

Thanks

Habeeb

Below is a copy of data from my netstat output.

LabVIEW.exe posting TIME_WAIT On Connections to Port 8089

Proto Local Address Foreign Address State PID

TCP 172.16.144.1:139 0.0.0.0:0 LISTENING 4
Can not obtain ownership information
TCP 172.16.144.1:445 172.16.144.2:60180 ESTABLISHED 4
Can not obtain ownership information
TCP 172.16.144.1:49773 172.16.144.1:49845 ESTABLISHED 4636
[sqlservr.exe]
TCP 172.16.144.1:49845 172.16.144.1:49773 ESTABLISHED 6364
[nicitdl5.exe]
TCP 172.16.144.1:51512 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51513 172.16.144.1:49773 TIME_WAIT 0
TCP 172.16.144.1:51514 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51515 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51516 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51517 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51518 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51519 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51520 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51521 172.16.144.1:49773 TIME_WAIT 0
TCP 172.16.144.1:51523 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51524 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51525 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51526 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51527 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51528 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51529 172.16.144.1:49773 TIME_WAIT 0
TCP 172.16.144.1:51530 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51531 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51532 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51533 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51534 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51535 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51536 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51537 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51538 172.16.144.1:49773 TIME_WAIT 0
TCP 172.16.144.1:51539 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51540 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51541 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51542 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51543 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51544 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51545 172.16.144.1:49773 TIME_WAIT 0
TCP 172.16.144.1:51546 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51547 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51548 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51549 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51550 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51551 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51552 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51553 172.16.144.1:49773 TIME_WAIT 0
TCP 172.16.144.1:51554 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51555 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51556 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51557 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51558 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51559 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51561 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51562 172.16.144.1:49773 TIME_WAIT 0
TCP 172.16.144.1:51563 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51564 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51565 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51566 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51567 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51568 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51569 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51570 172.16.144.1:49773 TIME_WAIT 0
TCP 172.16.144.1:51571 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51572 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51573 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51574 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51575 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51576 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51577 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51578 172.16.144.1:49773 TIME_WAIT 0
TCP 172.16.144.1:51579 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51580 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51581 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51582 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51583 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51584 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51585 172.16.144.1:49773 TIME_WAIT 0
TCP 172.16.144.1:51586 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51587 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51588 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51589 172.16.144.2:8089 TIME_WAIT 0
TCP 172.16.144.1:51590 172.16.144.2:8089 ESTABLISHED 4156
[LabVIEW.exe]
TCP 172.16.144.1:55481 172.16.144.2:445 ESTABLISHED 4
Can not obtain ownership information

[altenbach]

---

@habeebsiddique wrote:

I am not able understand why my LabVIEW application is doing this. Any pointers to what I should be looking in.

---

Most likely there is a bug in your program. Who wrote it?

(It seems this is a VI running in the LabVIEW development environment, not a built application. Is this correct?)

Are you constantly opening new TCP connections, for example? Can you attach a simplified version of your VI?

[Mark_Yedinak]

I suspect that you are opening/closing the TCP connection every time you get your data. The general rule of thumb would be to open the connection once and then continually get your data. Close the connection at the end when you are finished. The only time I will open/close the connection every time is when the communication frequency is very slow. Anything faster than once or twice a second I will open once and leave it open.

BTW, the TIMED WAIT state is part of the TCP protocol. It can vary slightly depending on what OS you are using but it will occur for every TCP connection when it is closed. This is by design. So if you are opening/closing very quickly you can exhaust the resources allocated to the TCP stack in the OS.

[habeebsiddique]

There could be a bug, but this program has been running smoothly for the last 5-7 years. 

The VI receiving the data is a built application. The data is received from an application on a remote computer using a shared variable.

I do not know if VI that is displaying the data is opening the TCP connections or if the application sending data to my VI is opening the TCP connections. Can you direct what I should look for to answer this question.

Thanks

Habeeb

[habeebsiddique]

The application sending the data to the LabVIEW VI has a reporting interval of 200ms. Based on this information, what you said makes completes sense. 

I need to find out if its is the LabVIEW VI that is opening/closing the TCP connections or if it is the application on the remote computer.

LabVIEW VI is using Shared Variables to get the data. Maybe I should be looking for the TCP connections open/close detail on the LabVIEW VI.

Thanks

Habeeb

[crossrulz]

---

@habeebsiddique wrote:

LabVIEW VI is using Shared Variables to get the data. Maybe I should be looking for the TCP connections open/close detail on the LabVIEW VI.

---

I have not trusted Shared Variables for at least a decade.  They are slow and often cause some really weird race conditions.  Use direct TCP communications whenever possible.

[Mark_Yedinak]

---

@crossrulz wrote:

---

@habeebsiddique wrote:

LabVIEW VI is using Shared Variables to get the data. Maybe I should be looking for the TCP connections open/close detail on the LabVIEW VI.

---

I have not trusted Shared Variables for at least a decade.  They are slow and often cause some really weird race conditions.  Use direct TCP communications whenever possible.

---

I concur. I have never really liked using them. I get much better results using the native TCP privatives and a basic application protocol. Created re-use libraries for these features and just drop them into any new application.