From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Woking with labview over multiple network interfaces
@billko wrote:I found this KnowledgeBase Article that seems to indicate that you can manually distinguish the two NICs by using TCP Listen.vi with TCP Create Listener.vi or you can simply use TCP Open.vi and let Windows worry about which card to use.
I guess you can do it both ways.
Listen and Open are not the same thing at all. One opens a listener socket, which is usually the server incoming side of things. In order for this to work it can be necessary in multi NIC setups to tell this node on which network subnets it should listen. For this you can wire the optional local network address to the Create Listener.vi. If this is wired with any of the locally assigned addresses to the various NICs including the loopback device, then the listen will only happen on that specific NIC and any incoming connection attempt from one of the other NIC will not even reach the listen function and simply go into the void.
When you use Open you really open an active socket and that, while on the BSD API socket level can be bound to a specific NIC, really should not need this at all. The IP address that you want to connect to already defines on which NIC this socket should be operating (that is as long as you do not configure overlapping subnet ranges but if you start to do that you have really a lot more and bigger troubles to solve than an unreachable remote PC). Basically if the IP address you want to connect to is inside one of the configured subnet ranges the connection is automatically routed to the according NIC, anything else goes to the default gateway address. And this is where it can get tricky. If you have more than one NIC and assign to each a gateway address then the socket library has a potential problem. It will select one of the configured gateways as default gateway and use this. There are three ways to solve this trouble:
1) reconfigure the NICs that only the one with a connection to the real outside world has a gateway. This will then be the only and at the same time default gateway.
2) use the ominous route command to change the default gateway to use.
3) Not in LabVIEW, bind the active socket on which you do the connect explicitedly to one of the NIC addresses.
From all of these options 1) and 2) solve the problem on system configuration level which is the right place to do this kind of stuff, 3) will make your application responsible for knowing explicitedly about your network setup which is basically always a bad thing.
LabVIEW never blasts out TCP packets on every NIC. It can't as TCP/IP is a connection oriented protocol and as such is monogamous and only can have a 1:1 relationship. The socket library will not send out any data packets before the connection is correctly established through the TCP handshake.
With UDP you do have a possibility to blast but here the UDP Open since I don't know how many LabVIEW versions does have a local IP address input "net address" that can be used to bind the according underlaying socket to a specific NIC.
@rolfk wrote:
@billko wrote:I found this KnowledgeBase Article that seems to indicate that you can manually distinguish the two NICs by using TCP Listen.vi with TCP Create Listener.vi or you can simply use TCP Open.vi and let Windows worry about which card to use.
I guess you can do it both ways.
Listen and Open are not the same thing at all. One opens a listener socket, which is usually the server incoming side of things. In order for this to work it can be necessary in multi NIC setups to tell this node on which network subnets it should listen. For this you can wire the optional local network address to the Create Listener.vi. If this is wired with any of the locally assigned addresses to the various NICs including the loopback device, then the listen will only happen on that specific NIC and any incoming connection attempt from one of the other NIC will not even reach the listen function and simply go into the void.
When you use Open you really open an active socket and that, while on the BSD API socket level can be bound to a specific NIC, really should not need this at all. The IP address that you want to connect to already defines on which NIC this socket should be operating (that is as long as you do not configure overlapping subnet ranges but if you start to do that you have really a lot more and bigger troubles to solve than an unreachable remote PC). Basically if the IP address you want to connect to is inside one of the configured subnet ranges the connection is automatically routed to the according NIC, anything else goes to the default gateway address. And this is where it can get tricky. If you have more than one NIC and assign to each a gateway address then the socket library has a potential problem. It will select one of the configured gateways as default gateway and use this. There are three ways to solve this trouble:
1) reconfigure the NICs that only the one with a connection to the real outside world has a gateway. This will then be the only and at the same time default gateway.
2) use the ominous route command to change the default gateway to use.
3) Not in LabVIEW, bind the active socket on which you do the connect explicitedly to one of the NIC addresses.
From all of these options 1) and 2) solve the problem on system configuration level which is the right place to do this kind of stuff, 3) will make your application responsible for knowing explicitedly about your network setup which is basically always a bad thing.
LabVIEW never blasts out TCP packets on every NIC. It can't as TCP/IP is a connection oriented protocol and as such is monogamous and only can have a 1:1 relationship. The socket library will not send out any data packets before the connection is correctly established through the TCP handshake.
With UDP you do have a possibility to blast but here the UDP Open since I don't know how many LabVIEW versions does have a local IP address input "net address" that can be used to bind the according underlaying socket to a specific NIC.
I never said they were the same thing.
@billko wrote:I never said they were the same thing.
Sorry, it wasn't meant as critique to your specific post, but I used your post to reply to since it wasn't very clear why Listen and Open would be different in that respect. Other posts like blasting out messages on every NIC would have been probably the more correct place to use as reply anchor :-).
@rolfk wrote:
@billko wrote:I never said they were the same thing.
Sorry, it wasn't meant as critique to your specific post, but I used your post to reply to since it wasn't very clear why Listen and Open would be different in that respect. Other posts like blasting out messages on every NIC would have been probably the more correct place to use as reply anchor :-).
LOL I was wondering why I just couldn't make the connection. 😄
