Thanks for your help guys! It would be most excellent to have that socket option turned off by default. It would certainly make multicast receivers written in java behave the same way across all the major platforms. Not sure why this wasn't considered a bug in Linux and, in fact, it's vehemently defended as absolutely adhering to the multicast spec.
For further context, please have a look at: https://bugzilla.redhat.com/show_bug.cgi?id=231899 Blessings, Brian On May 10, 2013, at 4:22 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > On 09/05/2013 21:49, Brian Call wrote: >> >> Hi Guys, >> >> My name is Brian Call and I'm a software developer for Sotera Wireless. I'm >> currently developing a relatively complex multicast application using the >> jdk7 selector-based I/O for multicast and I've run in to a pretty major >> hurdle. By "complex", I mean that I have a single bound socket joining >> multiple groups and it's critical that the bound socket only receive traffic >> for groups it has joined. I'm hitting the "promiscuous" traffic problem... >> and while bound to 0.0.0.0 on linux I'm getting traffic for all multicast >> groups, even if they were not specifically joined. In essence, there is no >> IP stack-level filtering for datagrams by joined group on linux unless you >> explicitly tell the stack to do so. Solaris and windows does the filtering >> by default and Linux does not. >> >> Is there any way to make use of a non-standard socket option in Java? Having >> spoken with Neil Horman lead networking developer over at Red Hat, he >> mentioned that by passing in the socket option IP_MULTICAST_ALL with a value >> of '0' it will disable UDP multiplexing on Linux when bound to the wildcard >> address. This would definitely be the hot move... >> >> If you have any insight into resolving the promiscuous multicast traffic >> problem in Java, I'd be more than grateful. > Thanks for you mail. I wasn't aware of IP_MULTICAST_ALL, this is very useful > to know because multicasting behavior on Linux has been painful because of > works differently to other platforms (particularly Solaris, Mac and Windows). > It may be that we need to consider setting IP_MULTICAST_ALL to 0 by default. > > As regards platform specific socket options then it is possible for a JDK > implementation to expose socket options beyond those specified. This is the > rational for the NetworkChannel setOption/getOption methods. This isn't > exactly what you want though, it's not a means to "bolt on" support for other > socket options to an existing JDK build. > > -Alan Blessings, Brian Call brian.c...@soterawireless.com PRIVILEGED AND CONFIDENTIAL COMMUNICATION: This electronic transmission, and any documents attached hereto, may contain confidential and/or legally privileged information. The information is intended only for use by the recipient named above. If you have received this electronic message in error, please notify the sender and delete the electronic message. Any disclosure, copying, distribution, or use of the contents of information received in error is strictly prohibited.
