Dear All, I implemented an UDP Multicast socket connection with boost. It works fine if I test server and client on the same PC (windows Xp or 7) but If server and client are (normally) on different PCs and at least on the client side there are virtual network cards active, the client does not receve udp data. It seems the udp connection uses one of the virtual cards and in that case it doesn't work. In fact If I deactivate all virtual cards then it starts working. Can you explain me please what's going on? Regards Gianni
If the client is on windows XP it works fine. Does anybody know if there is a problem related to Windows 7? Regards Gianni Il 3/26/2012 6:44 PM, Gianni Ambrosio ha scritto:
Dear All, I implemented an UDP Multicast socket connection with boost. It works fine if I test server and client on the same PC (windows Xp or 7) but If server and client are (normally) on different PCs and at least on the client side there are virtual network cards active, the client does not receve udp data. It seems the udp connection uses one of the virtual cards and in that case it doesn't work. In fact If I deactivate all virtual cards then it starts working. Can you explain me please what's going on?
Regards Gianni
If the client is on windows XP it works fine. Does anybody know if there is a problem related to Windows 7?
Hi Gianni, If you by "virtual network card" mean "loopback adapter" this is not a boost/asio issue, but caused by changes to TCP/IP stack in recent Windows version. You'll need to enable weak host receive/send on the interfaces: http://blog.loadbalancer.org/direct-server-return-on-windows-2008-using-loop... -- Best regards, Martin Dyring-Andersen
Hi Martin, Il 3/28/2012 10:38 AM, Martin Dyring-Andersen ha scritto:
If you by "virtual network card" mean "loopback adapter" this is not a boost/asio issue, but caused by changes to TCP/IP stack in recent Windows version. You'll need to enable weak host receive/send on the interfaces: http://blog.loadbalancer.org/direct-server-return-on-windows-2008-using-loop...
I mean the network adapter created by a virtualization tool (like VMware). I verified that a client on win7 with a such network adapter active does not work (I'm talking about udp multicast, while TCP works perfectly). On the other side if I disable the "real" card and then enable it again, udp starts magically working. Any idea? Regards Gianni
On 3/28/2012 7:41 AM, Gianni Ambrosio wrote:
I mean the network adapter created by a virtualization tool (like VMware). I verified that a client on win7 with a such network adapter active does not work (I'm talking about udp multicast, while TCP works perfectly). On the other side if I disable the "real" card and then enable it again, udp starts magically working.
Any idea?
I don't have a link for this, but I know well that, on a Windows machine with more than one NIC (network adapter), outgoing broadcast messages have the FIRST network adapter's address as the return address on messages going out all NICs. The receiver on the second network uses that (wrong) address for the response, and the response doesn't get back to the PC. Disabling and enabling may switch which NIC is considered first (not sure about that). I've seen this on Windows XP but haven't tried to repeat it on Windows 7. The problem is in the OS. Hope that helps. -Jim
Hi Jim Il 3/28/2012 8:24 PM, Jim Bell ha scritto:
I don't have a link for this, but I know well that, on a Windows machine with more than one NIC (network adapter), outgoing broadcast messages have the FIRST network adapter's address as the return address on messages going out all NICs. The receiver on the second network uses that (wrong) address for the response, and the response doesn't get back to the PC. Disabling and enabling may switch which NIC is considered first (not sure about that).
I've seen this on Windows XP but haven't tried to repeat it on Windows 7. The problem is in the OS.
Thanks for the answer but I'm not sure to understand exactly. In my case the sender has just one NIC. The problem seems on the client in which there's one or more NIC created by VMWare. The client, in my case, just listens to udp datagrams and never needs to send anything. Regards Gianni
Il 3/28/2012 8:24 PM, Jim Bell ha scritto:
On 3/28/2012 7:41 AM, Gianni Ambrosio wrote:
I mean the network adapter created by a virtualization tool (like VMware). I verified that a client on win7 with a such network adapter active does not work (I'm talking about udp multicast, while TCP works perfectly). On the other side if I disable the "real" card and then enable it again, udp starts magically working.
Any idea?
I don't have a link for this, but I know well that, on a Windows machine with more than one NIC (network adapter), outgoing broadcast messages have the FIRST network adapter's address as the return address on messages going out all NICs. The receiver on the second network uses that (wrong) address for the response, and the response doesn't get back to the PC. Disabling and enabling may switch which NIC is considered first (not sure about that).
I've seen this on Windows XP but haven't tried to repeat it on Windows 7. The problem is in the OS.
Dear All, I found that the IP address of the network interface of the client used for the socket connection would be enough to solve the problem. Now, is there a way to get that IP address? I also use a TCP socket connection before starting the UDP multicast. Is there a way to get the IP related to the network card connected to the TCP socket? Here is my actual code. I need to find a way to get the IP "192.168.0.85" that is the address of the network card of client (that calls receiveFrom() method) void BoostUdpSocketMulticast::receiveFrom(const std::string& iMulticastAddress, const unsigned short iMulticastPort) { boost::system::error_code error; boost::asio::ip::address_v4 m_address = boost::asio::ip::address_v4::from_string(iMulticastAddress, error); boost::asio::ip::address_v4 l_address = boost::asio::ip::address_v4::from_string("192.168.0.85", error); endpoint=boost::asio::ip::udp::endpoint(l_address, iMulticastPort); socket.open(endpoint.protocol()); socket.set_option(boost::asio::ip::udp::socket::reuse_address(true)); socket.bind(endpoint); // join the multicast group on a specific interface boost::asio::ip::multicast::join_group option(m_address,l_address); socket.set_option(option); } Regards Gianni
Il 4/4/2012 9:31 AM, Gianni Ambrosio ha scritto:
void BoostUdpSocketMulticast::receiveFrom(const std::string& iMulticastAddress, const unsigned short iMulticastPort) { boost::system::error_code error; boost::asio::ip::address_v4 m_address = boost::asio::ip::address_v4::from_string(iMulticastAddress, error); boost::asio::ip::address_v4 l_address = boost::asio::ip::address_v4::from_string("192.168.0.85", error); endpoint=boost::asio::ip::udp::endpoint(l_address, iMulticastPort); socket.open(endpoint.protocol()); socket.set_option(boost::asio::ip::udp::socket::reuse_address(true)); socket.bind(endpoint); // join the multicast group on a specific interface boost::asio::ip::multicast::join_group option(m_address,l_address); socket.set_option(option); }
Why boost join_group does not work with a general boost::asio::ip::address and an explicit conversion to ipv4 or ipv6? It seems it should be transparent just like other piece of boost code. Regards Gianni
participants (3)
-
Gianni Ambrosio -
Jim Bell -
Martin Dyring-Andersen