MulticastSocket is missing a (port, addr) constructor; it always binds to INADDR_ANY. This is bad. The problem is that the underlying OS does not do any packet filtering based on which sockets have actually joined which groups. As such, if process A opens a MulticastSocket on port P and joins group G1, and process B opens a MulticastSocket on the same port P but joins group G2, both sockets will now receive packets sent to either group, not just the packets sent to the one group they joined. This situation occurs daily in normal use of Jini(TM) technology: multicast requests and multicast announcements are done using different multicast groups, but the same port. Since there's also no way to tell what the destination address was for a received packet (only the source address), code attempts to parse announcement packets as if they were request packets, and vice versa, which fails because the packet formats are different. This would be resolved by allowing binding to a specific address (we'd bind to the multicast group).

manish.dixit@west 2000-04-21
Attached is a program called "MulticastTest". Run it in two terms on a
multihomed machine. In one term run it as: "java utils.MulticastTest -N
ONE -A <address 1>" in the other: "java utils.MulticastTest -N TWO -A
<address 2>" They will bind to port 7001 by default. You should see
crosstalk between the two terms. We have had customers report this for
Solaris 2.6 and Solaris 2.7.

Attached is the MulticastTest.java program