TCP listen takes long time to get connection

[AndyN]

---

The J wrote:

I realize that I'm replying to this thread over a year late, but I hope that someone else will find this useful.  I'm working on implementing FTP in LabVIEW and didn't get why FileZilla could get the directory listing so fast when my LabVIEW VI took 5 or 6 seconds to do so.  Wireshark (an ethernet analyser) was showing that the packets were coming in quickly, but LabVIEW was getting stuck on waiting for a listener.

I eventually figured out that I needed to wire False to the Resolve Remote Address input on the bottom of the VI.  The help says that this just calls IP To String, but then I remembered that the function will actually try to resolve the IP (unless you tell it to use the dot notation).  So now it's much faster.  Wire False to the bottom input of the TCP Listen VI unless you actually need to resolve an address (I don't since I'm connecting to a controller board).

Hope someone finds this useful.

---

Another year later... You are my hero!. It fixed my problem too. Great job!

[Ben_Engelen]

Almost 2 years later, but it also fixed my problem.

Thanks!!

[CMulaisho]

3+ years and this thread solved my problem as well.  Weird thing was we've tested numerous network configuration scenarios and have only hit it with our production configuration.  Was an interesting afternoon debug.

[steve_robbins]

Even in 2013 your post is helping me solve a nagging connection delay.  Thanks for posting your solution!

[mfitzsimons]

Glad to hear it is still solving problem today. 

[AndyN]

I think it should be made off by default. I cant see any benefit to keep it on.

[Z.Chen]

5 years later, this reply still solved my problem.

I was wondering why NI simply don't change the default value.

Hope I could give you more Kudos on this.

Thank you very much.

[rolfk]

Changing default values is a very dangerous thing. Applications that worked properly may suddenly fail fatally when upgraded to a new version that changed default behaviour. This is something the LabVIEW developers are VERY careful with.

The problem is in fact a misconfigured network. If you have a proper name resolution setup in your netwok, the IP to String name resolution should only add some milliseconds to the delay. If you have no DNS name resolution at all, or a DHCP server that is misconfigured and gives out invalid DNS server settings, then you run into the observed delays where the call to IP to String will eventually timeout. This timeout luckily is not treated as fatal error and the connection is eventually returned successfully (unless your listen timeout is shorter than the configured DNS lookup timeout) but the remote address will only contain the dot notation name and not a resolved DNS name.

[Z.Chen]

Hi,

How do I test if it's properly configured or not?

The only thing I know is that windows does responce quite quickly to hostnames.

[rolfk]

Well, if IP to String takes more than a second or so, something is fishy (or you are connected to the internet through a dialup modem from the last century )

hostname resolution is the opposite and corresponds to String to IP, which usually works quite fine or you will find out right at the moment you enter a webaddress in your browser.