LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Issues with UDP functions on Multihomed PC

We have two machine on that one machine(Multihomed) has two ethernet Channels and other machine has 1 Ethernet channel.
The Multihomed machine IP numbers as follows.
Channel1 192.168.200.19 & Channel2 192.168.200.101 and the other Single Ethernet Channel machine has IP number as 192.168.200.11

 

I am facing couple of issues with UDP functions.

I am facing a problem with UDP functions on Multihomed PC(two ethernet Channel on same machine.). On the multihomed PC I created an UDP open reference for IP 192.168.200.101, Port 9000
and send data packet to the destination machine(IP: 192.168.200.11, Port 9001) using UDP Write function.
On the destionation machine I created UDP Open reference for 192.168.200.11, Port 9001 and read Using UDP Read function.The data are received correctly, Except the IP address of the datagram Originates.
I am sending the datagram from 192.168.200.101 and on UDP read function it should show the Originated IP as 192.168.200.101, but shows as 192.168.200.19.

 

The other problem I noticed with UDP function is that eventhough I give wrong IP address which is not exist on the machine, the UDP open doesn't gives any error and works fine for Write UDP datagram and the same UDP open reference fails for listen UDP datagram.

 

Please suggest the way to overcome the issues.

0 Kudos
Message 1 of 4
(3,789 Views)

sathiya wrote: 

 

On the destionation machine I created UDP Open reference for 192.168.200.11, Port 9001 and read Using UDP Read function.The data are received correctly, Except the IP address of the datagram Originates.
I am sending the datagram from 192.168.200.101 and on UDP read function it should show the Originated IP as 192.168.200.101, but shows as 192.168.200.19.

 



When you specify the net address using UDP Open, the address only applies to listen (read functions) see the online help. LabVIEW runs on Windows and OSX, and uses the OS to handle the low-level TCP/IP functions. When your write a UDP datagram, LabVIEW lets the OS decide which interface to use to send the message. 

 

Your IP addresses are typical 'private network' class C addresses (netmask = 255.255.255.0) Since both of your network interfaces are on the same subnet, Windows uses internal settings and metrics to determine which interface to use. LabVIEW has no influence over the selection. UDP is a broadcast, so it shouldn't really matter which network interface transmitted the data, it got there, right?

 

It's generally not a good idea to have two network interfaces in a computer with the same subnet connected to the same physical LAN.  If you are trying to separate or isolate the traffic, you need a separate subnet address AND a separate physical LAN (use a crossover cable or separate hub).

 

You might be able to affect limited control by setting IP options such as static routes or network interface metrics at the OS level.


sathiya wrote:

 The other problem I noticed with UDP function is that eventhough I give wrong IP address which is not exist on the machine, the UDP open doesn't gives any error and works fine for Write UDP datagram and the same UDP open reference fails for listen UDP datagram.

 


Again, the address you are specifying at the Open is the listen address. LabVIEW will LISTEN for UDP datagrams on this net address. It appears that Open creates a valid Connection ID, but the connection is effectively 'write only'. Check the error out of the UDP Open function for an error.

Message 2 of 4
(3,773 Views)

Hi,

Thanks for the reply.


When you specify the net address using UDP Open, the address only applies to listen (read functions) see the online help.

LabVIEW runs on Windows and OSX, and uses the OS to handle the low-level TCP/IP functions. When your write a UDP datagram, LabVIEW lets the OS decide which interface to use to send the message. 


From your comment I understood how the LabVIEW handles on Write a UDP datagram. Alternatively on using C++ I implemented socket creation and sent datagram. The issue did not occur and the receiving side shows the correct datagram originating IP address. 

So what would be the workaround on LabVIEW to write UDP datagram from specified IP on multihomed PC.  Because this functionality is important for my application on which we are using 24 Ethernet channel on a single PXI system.

0 Kudos
Message 3 of 4
(3,740 Views)

I don't program in c++, but a little searching suggests that a socket is created and then that socket is bound to a local IP addess and port.

 

LabVIEW does not provide an option to specify which local IP address to bind to. This may have something to do with portability between platforms (linux and OSX). A windows socket does not seem to be the same thing as a LabVIEW connection ID.

 

There is a way to get the raw net object from LabVIEW and then manipulate the lower level OS options, but this would need to be done carefully. I have successfully modified the OS level receive buffer size for a LabVIEW UDP connection; see this thread.

 

You might be able to use spcific wsock32 calls to configure the connection to specify a local address. I've never done this. Maybe someone else can help from this point.

 

 

Good luck!

 

0 Kudos
Message 4 of 4
(3,706 Views)