Rendezvous Linux issue with Multicast

I saw the following in a recent Rendezvous release note.

However,  this is not a problem with Linux multicast that I have ever seen.

Linux does have a multicast problem where if two process/threads open up the exact same socket with SO_REUSEADDR but two different multicast addresses that a process/thread can get data for a multicast address it did not subscribe to.  This is now fixed with the IP_MULTICAST_ALL socket option in Linux kernels 2.6.31 and later.   Rendezvous should never have this issue though as the RV UDP Port it binds does not use the SO_REUSEADDR socket option. 

Linux should always filter out data at the port level though.  Placing data on a socket to a port not bound by that socket would be a pretty serious bug in the kernel under any circumstance.    I am curious what Linux kernel the below problem was found in.  I can't imagine you would see that issue on Redhat 5 or SUSE 11 nowadays.  I have never seen this problem and have explicitly looked for it on Linux and Solaris.  



Linux Delivers Multicast Data to All UDP Ports

Consider two receivers, R1 and R2, which run on thesame Linux host

computer. R1 binds UDP service U1, and joinsmulticast listen group M1.

Similarly, R2 binds UDP service U2, and joinsmulticast listen group M2.

A sending program, S, runs on any other hostcomputer across a network. S

sends messages over UDP service U1 to multicastsend address M2. Receiver

R2 receives these messages, even though one wouldexpect its service (U2) to

preclude this behavior.

The behavior is specific to Linux, and not specificto Rendezvous. Simple

multicast socket programs produce the same behavioron Linux.


Use distinct multicast addresses to separatemessage streams (do notrely on

UDP services to separate message streams). Do notreuse a same multicast

groupaddress on different UDP services.