Localhost needed on TCP Open Connection

[Aitor Solar]

Hi, people.

I've found a surprising behavior in the TCP Open Connection VI.

Simply put, if you open a TCP connection from LabVIEW to another application in the same computer, using the "TCP Open Connection.vi", and you don't wire anything to the address input, connection works ok. But if then you unplug the ethernet cable from the machine, your connection will be closed in a few seconds (the OS, I'm guessing). Now, if you explicitly use as address "localhost" or 127.0.0.1 in that VI, the TCP connection will survive any plugging / unplugging of the ethernet cable.

Moreover, if you start the connection with cable unplugged, the connection will survive any further plug/unplug even if you didn't explicitly set it to localhost. This on Windows XP at least.

You can easily test this behavior with the Simple Data Client.vi and Simple Data Server.vi examples found on LV. Run as they are provided and unplug the cable: ok. Disconnect the address wire on de client, repeat process and get error 66 in a few seconds.

Saludos,

Aitor

[Rolf Kalbermatter]

Hi, people.

I've found a surprising behavior in the TCP Open Connection VI.

Simply put, if you open a TCP connection from LabVIEW to another application in the same computer, using the "TCP Open Connection.vi", and you don't wire anything to the address input, connection works ok. But if then you unplug the ethernet cable from the machine, your connection will be closed in a few seconds (the OS, I'm guessing). Now, if you explicitly use as address "localhost" or 127.0.0.1 in that VI, the TCP connection will survive any plugging / unplugging of the ethernet cable.

Moreover, if you start the connection with cable unplugged, the connection will survive any further plug/unplug even if you didn't explicitly set it to localhost. This on Windows XP at least.

You can easily test this behavior with the Simple Data Client.vi and Simple Data Server.vi examples found on LV. Run as they are provided and unplug the cable: ok. Disconnect the address wire on de client, repeat process and get error 66 in a few seconds.

Saludos,

Aitor

The underlaying getaddrinfo() at least on Windows, will return all local network adapter addresses and LabVIEW will pick the first one from that list to use. So it binds to the actual default IP address of your machine. When you disconnect the cable this IP address (and adapter) gets invalid and your connection is working through an unconnected socket, which of course gives errors.

When the cable is not connected at the time the address is resolved and the socket is bound, the first adapter returned will be a different one, it could be the loopback interface or your WIFI interface. So connecting the cable and disconnecting it does not have any influence on this connection.

Using 127.0.0.1 or localhost explicitedly will bind to the loopback adapter and that one is valid for as long as Winsock is working, aka. until you shutdown your computer.

[Phillip Brooks]

Hi, people.

I've found a surprising behavior in the TCP Open Connection VI.

Simply put, if you open a TCP connection from LabVIEW to another application in the same computer, using the "TCP Open Connection.vi", and you don't wire anything to the address input, connection works ok. But if then you unplug the ethernet cable from the machine, your connection will be closed in a few seconds (the OS, I'm guessing). Now, if you explicitly use as address "localhost" or 127.0.0.1 in that VI, the TCP connection will survive any plugging / unplugging of the ethernet cable.

Moreover, if you start the connection with cable unplugged, the connection will survive any further plug/unplug even if you didn't explicitly set it to localhost. This on Windows XP at least.

You can easily test this behavior with the Simple Data Client.vi and Simple Data Server.vi examples found on LV. Run as they are provided and unplug the cable: ok. Disconnect the address wire on de client, repeat process and get error 66 in a few seconds.

Saludos,

Aitor

My guess would be that when a cable is plugged into the Ethernet port, the adapter is active and Windows returns the IP address assigned to the network card on the open request. When you pull the cable, Windows informs any active sockets that the state has changed and your connection is closed by LabVIEW.

If no cable is connected, Windows returns the loopback address as the only valid adapter. If you explicitly request localhost, this is resolved to 127.0.0.1 and never uses the physical interface.

http://en.wikipedia.org/wiki/Localhost

Communicating with the loopback interface in an identical manner as with another computers on the network,

but bypassing the local network interface hardware, is useful for the purposes of testing software.

[Aitor Solar]

Thank both of you, it seems logical when you think of it, but I had always thought that leaving that wire unconnected was exactly the same as using "localhost" .

Saludos,

Aitor

[torekp]

Thank you all, you just saved me a lot of experimentation!

[torekp]

Related question: does this apply to VI server also? That is, do I need to explicitly open an application reference using "localhost", rather than just opening a VI reference, for fear that the network connection may get disconnected.

[MikaelH]

Thank both of you, it seems logical when you think of it, but I had always thought that leaving that wire unconnected was exactly the same as using "localhost" .

Saludos,

Aitor

I just found out this as well.

I have the same exe-file using the TCP/IP Connect without the localhost string connected.

It then works on my XP machine, but not on my W7-64 bit.

But by adding localhost, it now work on both OSs.

Cheers,

Mike

[Rolf Kalbermatter]

Related question: does this apply to VI server also? That is, do I need to explicitly open an application reference using "localhost", rather than just opening a VI reference, for fear that the network connection may get disconnected.

When you leave the address input open to Open Application Reference, LabVIEW does make a short-cut connecting directly to itself rather than routing everything through TCP/IP. So it's a bit different than the TCP/IP nodes.