LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to close TCP port in LV 4.1?

I've used the "TCP Listen" VI and the combination of "TCP Create Listener" & "TCP Wait on Listener" to accept a socket connection. That works fine, but I do not want the app to listen for any more requests once it has a connection. I would expect "TCP Listen" to close the listener once it has a connection, but it does not. When using the Create/Wait Listener VIs I call "Close Connection" on the Listener and even though I do not get an error, the port is still being listened to.
What could be going wrong?
0 Kudos
Message 1 of 15
(3,630 Views)

Could you post an IMAGE (LV 4.1 is getting scarce these days) of your code so we can take a look?

It sounds as if the listen is being invoked again.

There have been some changes and fixes implemented since LV 4.1 so I can not say that I have seen this issue previously.

Trying to offer what little help I can,

Ben


Ben Rayner
Certified LabVIEW Developer
www.DSAutomation.com

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 2 of 15
(3,630 Views)
Thanks for responding.
Going to reply in multiple posts as I have more than 3 attachments.

The first attachment (orig.jpg) is what existed when I noticed that listening socket seemed to be staying open. This is very similar to an NI tcp server example which I'm attaching as well (example.gif). I don't have the code anymore, but I did modify the existing code to replicate the example exactly and I still saw the same behavior.
Download All
0 Kudos
Message 3 of 15
(3,630 Views)
I also tried the other method of creating a listener, waiting on the listener, and closing the listener when a connection is made. The close of the listener returned "success" yet a "netstat -a" still showed that it was still listening on that port.

Thanks again,
Kevin
Download All
0 Kudos
Message 4 of 15
(3,630 Views)
A note on the "close listener" diagram: The "abort" input terminal was documented as being ignored, though I still tried giving it a "true" when the default "false" didn't seem to work.
0 Kudos
Message 5 of 15
(3,630 Views)
OK,

How about an image of how these sub-VI are being called.

The extensive use of Globals makes me nervous but I can not spot anything solid that would cause me to suspect a race condition.

Images of these VI's being called will shut me up.

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 6 of 15
(3,630 Views)
The sub-vi has multiple callers, but there's only one call per message id. Attached is one of the callers.
0 Kudos
Message 7 of 15
(3,630 Views)
Is there any possibility to get this app loaded and saved as at least LV 6.0?

At the current rate, I am running the risk of wasting alot of your time before I can be sure if I can even help!

Short of that, I am concerned about race conditions due the extensive use of globals.

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 8 of 15
(3,630 Views)
I can't get it saved in a newer version...
Do you really think the globals could be part of the problem? I may try to write a test app with the connection code minus the globals to see if that behaves any differently.

Thanks,
Kevin
0 Kudos
Message 9 of 15
(3,630 Views)
Not the globals themselves but how they are used.

I never use globals I devlop myself.

I have worked with them in others code.

I suspect a race condition that is a result of over using globals.

If I could look at the entire app, I may be able to spot the race condition.

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 10 of 15
(3,630 Views)