TCP listen takes long time to get connection

[ogebler]

Thanks jdeguire, another problem solved! This was causing a real headache when attempting to connect to a MODBUS slave built in LV from Python. No idea why this input is set to TRUE by default....

[labviewman]

15 years later, and this post is still relevant! 

I am developing a HMI to control/monitor a HDMI Matrix, 4 HDMI MultiViewers, a USB Matrix, a UPS (via Modbus), and 3 smart power strips. All of the equipment is in use so I have to use simulators I am writing which is where I came across the "TCP Listen.vi" delay. The HMI code is targeted for RT, but can also run on Windows.

I saw always saw a 4.52 delay in "TCP Listen.vi" returning once a connection was established, but only when the connection was being made from a cRIO RT (RT Linux) to Windows, never Windows to Windows or Windows to RT, or RT to RT... only with RT to Windows. All tests done on a closed local network using static IP...no DHCP or DNS server (nor are they needed with a closed network with static IP).

I'm a bit perplexed in the inconsistent results such that only RT (client) to PC (server) had the issue.

[gabriel.brunheira]

It's 2024, I'm using LabVIEW 2019 with a compactRIO cRIO-9049 to communicate with other equipments as a TCP Server, and this answer from jdeguire helped me as well. I just set False to the Resolve Remote Address, and the time to get the connection from TCP Listen VI dropped from 4 seconds to almost instantly.

[pincpanter]

Very useful information. Actually I had problems some times ago to connect my applications via TCP. There was a "master" periodically querying data to "slaves"; the problem was that sometimes the roundtrip time was about 4-5 seconds, which was unacceptable. After careful tests, it turned out that the TCP server was accepting the connection with a delay. Changing the connection from cabled to wireless made the timing to improve. I could not understand the reason of those delays, so I ended up using UDP instead of TCP. However, I'm not sure the issue was due to the implicit IP To String call, since it was erratic.

I agree with rolfk that changing default values is not the right way to go, however I think that the help on TCP Listen should clearly state about the possibility of this issue.

[gabriel.brunheira]

Hi Paolo!

I fully agree with you and rolfk regarding caution when changing default values. However, I'm not sure I get the risks in the discussed case here.

I understand from rolfk that this delay for the default case may indicate something wrong with the DNS server, etc. But the non-default case (setting resolve remote address to False) would only imply that remote address outputs in the IP dot format (such as 128.0.0.25), instead of hostname (such as machinename.domain.com). How does it represent a problem to an application itself?

Anyway, I also agree this should be clearly stated in the TCP Listen help!

Gabriel

[rolfk]

---

@gabriel.brunheira wrote:

Hi Paolo!

I fully agree with you and rolfk regarding caution when changing default values. However, I'm not sure I get the risks in the discussed case here.

I understand from rolfk that this delay for the default case may indicate something wrong with the DNS server, etc. But the non-default case (setting resolve remote address to False) would only imply that remote address outputs in the IP dot format (such as 128.0.0.25), instead of hostname (such as machinename.domain.com). How does it represent a problem to an application itself?

Anyway, I also agree this should be clearly stated in the TCP Listen help!

---

Well, if you change that value in your app, that is of course your choice and you know best what you do with that string, if anything. What I meant to be pretty much a no-go, would be for NI to change that default value now. Any application that has been written in the past and left that input open to get a resolved hostname and then tries to parse that hostname and expecting a real name but finding a dot seperated numeric host address would be f*cked. 😁

[gabriel.brunheira]

Oh, I see your point now and I totally agree!

The best thing NI could do by now is to include this information in the help section, for TCP Listen and TCP Wait on Listener VIs and IP to String function.