Boost C++ Libraries: Ticket #6446: Mulicast receiver does not work

status, severity changed; resolution set

chris_kohlhoff — Tue, 29 May 2012 01:22:12 GMT

status new → closed
resolution → worksforme
severity Showstopper → Problem

Most likely you have multiple network cards and the default route does not match the interface you need to use for the multicast group. You need to either:

get your system administrator to add a route for the multicast group that uses the correct device; or

change your code to use the two-argument join_group constructor that lets you specify the interface.

Most likely the Java application does the latter. As multicast group subscriptions are system-wide, this makes your application work too. However, the first option is IMHO the preferred approach.

dieer.mayer@… — Sun, 10 Jun 2012 21:13:25 GMT

Chris,

have you tried the testprogramm ? have you understood my problem report ?

best regards

Dieter

chris_kohlhoff — Wed, 27 Jun 2012 11:48:04 GMT

I understood your problem report... The behaviour you describe is consistent with a routing issue.

anonymous — Wed, 27 Jun 2012 12:26:17 GMT

Hi, A Java mcast reader wirks fine, a pure C mcast readers works also, only The boost base reader is a problem

Best regards Dieter

chris_kohlhoff — Wed, 27 Jun 2012 12:56:19 GMT

As I said, it looks like a routing issue. Please note my first comment, in particular:

Most likely the Java application [uses the equivalent of the two-argument join_group constructor]. As multicast group subscriptions are system-wide, this makes your application work too.

You need to explore one of the two options I outlined in my first comment.

cgarcia — Wed, 04 Jul 2012 18:40:16 GMT

Boost examples are wrong, doesn't work in linux for machines with several network interfaces. Proper truly working code snippet for receiving on network interface 1.2.3.4:

std::string address_listen = "1.2.3.4"; std::string address_mcast = "224.0.0.0"; unsigned short address_port = 50000; boost::system::error_code ec; boost::asio::ip::address listen_addr = boost::asio::ip::address::from_string(address_listen, ec); boost::asio::ip::address mcast_addr = boost::asio::ip::address::from_string(address_mcast, ec); boost::asio::ip::udp::endpoint listen_endpoint(mcast_addr, address_port); socket.open(listen_endpoint.protocol(), ec); boost::asio::ip::udp::socket socket.set_option(boost::asio::ip::udp::socket::reuse_address(true), ec); socket.bind(listen_endpoint, ec); socket.set_option(boost::asio::ip::multicast::join_group(mcast_addr.to_v4(), listen_addr.to_v4()), ec);

cgarcia — Wed, 04 Jul 2012 18:43:41 GMT

Sorry for the improper code formatting. Repeated here:

    std::string address_listen = "1.2.3.4";
    std::string address_mcast = "224.0.0.0";
    unsigned short address_port = 50000;
    boost::system::error_code ec;
    boost::asio::ip::address listen_addr = boost::asio::ip::address::from_string(address_listen, ec);
    boost::asio::ip::address mcast_addr = boost::asio::ip::address::from_string(address_mcast, ec);
    boost::asio::ip::udp::endpoint listen_endpoint(mcast_addr, address_port);
    socket.open(listen_endpoint.protocol(), ec); // boost::asio::ip::udp::socket
    socket.set_option(boost::asio::ip::udp::socket::reuse_address(true), ec);
    socket.bind(listen_endpoint, ec);
    socket.set_option(boost::asio::ip::multicast::join_group(mcast_addr.to_v4(), listen_addr.to_v4()), ec);

chris_kohlhoff — Wed, 04 Jul 2012 23:49:32 GMT

Thanks for your comment, but the examples are not wrong. The approach shown in the examples works on multi-homed hosts provided you have configured the host's routing table correctly. However, you are correct that the two-argument join_group constructor is a valid alternative (although IMHO not generally preferred) approach, as I indicated in comment 1.

status changed; resolution deleted

Ludwig Schultze — Sat, 31 Oct 2015 00:19:44 GMT

status closed → reopened
resolution worksforme

Request to reopen and fix receiver.cpp.

sender.cpp is ok. Like Chris wrote, the routing table of the OS can be used to select the network interface through which to send outgoing multicast traffic. But sending was never the topic of this bug.

There might exist operating systems that use the routes for outgoing multicast traffic to also have the network interfaces join multicast groups for incoming traffic. At least Linux is not one of them.

As a result, the following does not work on Linux. It is the shell transcript of an attempt to use the kernel routing tables to make receiver.cpp work as suggested by Chris:

# MCAST_IP=<your multicast group>
# ETH0_IP=<your IP of eth0 network interface>
# sudo route add $MCAST_IP dev eth0
# ./receiver $ETH0_IP $MCAST_IP

This does not detect multicast packets of group MCAST_IP that arrive at eth0.

The packets are only detected if receiver is invoked as

./receiver 0.0.0.0 $MCAST_IP

but this receives also packets to the same port in all other multicast groups currently joined. Most likely because 0.0.0.0, being IPADDR_ANY, matches all multicast groups.

Thanks to cgarcia for sharing the correct code.