TCP Open Briefly hangs LabVIEW

[SteveChandler]

Hello LabVIEW forum! Long time no see. I have been away from LabVIEW doing other things but.... I'm back.

Background:

I am working on a project where I need to make a TCP connection to a Windows 7 machine. The Windows machine will intentionally reboot for each test. When it boots i need to make a TCP connection to a server that automatically starts on the Windows machine and send some commands. While it is booting, I try to connect, get an error, try again, etc until the connection is made.

The problem:

This machine name is not resolved by DNS or the hosts file. If I try to connect using a host name, and the host name cannot be resolved, LabVIEW will freeze for a few seconds. If I click the red abort button I get the not responding error. It will eventually recover and give me an error 54. The timeout is not relevant in this situation. It doesn't matter how long or how short I set it to, it always hangs LabVIEW for about three to five seconds. If I try to connect by IP number instead, then I don't see this problem. If the machine is off I just get a timeout error but LabVIEW doesn't freeze.

I cannot post code but try this: Write a VI with an infinite while loop and an indicator connected to the i terminal and place a 100mS delay in it. Run that and notice that the number increments. Now create and run a second VI with the TCP open in it and use a machine name that does not exist. What I see is that the number in the first VI will quit incrementing. I am using LabVIEW 2014 32 bit on Windows 7 Ultimate 64 bit. First open a console and try to ping the non-existant name you are trying to connect to and verify that it doesn't print an ip number. Some Internet providers will resolve all non existant hostnames to an IP they own for their own gain. If that is the case then you will not be able to duplicate this bug.

I have a workaround (put an entry in my hosts file) but I thought I would mention this possible bug. Plus it gives me an opportunity to say hi to all my old friends on my favorite fourm! (the list is long but you know who you are)

[Bob_Schor]

I'm uncertain as to the nature of the problem.  Are you saying that if LabVIEW tries to access a machine using DNS, and the machine by that name does not exist, that LabVIEW will hang for a bit?  Is the problem that LabVIEW takes a long time to "fail" in this case?  I'm not sure why this constitutes a "bug" -- maybe LabVIEW is just "making sure" before giving up.

Do you get problems if you specify a name that can be resolved?

Bob Schor

[dan_u]

Do you also see this short freeze if you just use the "String to IP" function? I guess TCP open will have to use this in the background when providing a host name.

Maybe this is rather a DNS lookup issue than a TCP open issue.

If I try that here the String to IP takes quite some time until it returns when the hostname does not exist. If I use nslookup from the command line I get an immediate response that the host does not exist.

[rolfk · Accepted solution]

LabVIEW calls Winsock for all network operations. Most of the Winsock operations are synchronous. This is not a big problem for most of LabVIEW code as LabVIEW is multithreading and executes the nodes in whatever thread the current VI is at. However some functions need to access some global data space and are protected by some means. This can be a global mutex and sometimes it's also solved by forcing the node to always execute in the UI thread of LabVIEW which also executes the windows message loop and Winsock does hook into that message loop to do its own internal pseudo synchronous operation.

The check for Adres to IP is something you can try. It may also lock up because of the internal Winsock hooking into the application message loop, but maybe it won't so that you can circumvent the problem. There is no way for an applciation using the normal Winsock API to avoid internal Winsock timeouts for synchronous functions, and the adress resolutino API does not really support asynchonous variants.

[dan_u]

Rolf, do you have an idea why the String to IP function takes ~2.2s (on my system) for an invalid hostname while the nslookup responds immediately?

[Norbert_B]

Does this delay depend on the user rights of the application? Which means: does it behave different if executed "Run as Admin"?

Also, there might be impacts by Firewall and/or Anti-Virus software. I don't know about any possible differences between command line window and LabVIEW (process-wise), but i can imagine that CMD is indeed treated differently.

As a workaround: You can call any application you would use in CMD with SystemExec.vi. Maybe the performance is better with this approach even though you have to make some string-handling and THEN react by opening the TCP connection.....

Norbert

[SteveChandler]

Dan, yes I do see this freeze with String to IP.

Bob, yes LabVIEW actually freezes. The second test VI running a simple while loop will stop spinning. I just noticed that it only sometimes stops spinning. What will always happen is that if you press the abort button while TCP open is figuring out that the host does not exist you will get the not responding situation. If you try connecting by IP to a host that does not exist, you can press abort and it will imediately abort. If I try connecting to a machine that can be resolved (or by IP address) then I do not see any problem.

[SteveChandler]

I think Rolf is right.

[SteveChandler]

Hey Norbert, yes I am running as admin. But I already have a workaround which is put an entry for the machine in my hosts file. I'm not really looking for another solution but was just curious why this is happening. Rolf's comment supports my suspicion that it has nothing to do with LabVIEW since it is at the mercy of the OS.

[dan_u]

---

@SteveChandler wrote:

Hey Norbert, yes I am running as admin. But I already have a workaround which is put an entry for the machine in my hosts file. I'm not really looking for another solution but was just curious why this is happening. Rolf's comment supports my suspicion that it has nothing to do with LabVIEW since it is at the mercy of the OS.

---

I kind of agree, but if this were completely true then why is the nslookup response immediate? Doesn't it use the same underlying Winsock function? Maybe Rolf knows about this.