Date:        Thu, 23 Oct 2003 22:37:04 -0700
    From:        "William A.Carrel" <william.a@carrel.org>
    Message-ID:  <19A1094E-05E4-11D8-B2E9-003065D5E9A4@carrel.org>

  | The behavior is contrary to the documentation for setsockopt

I can believe that's possible.

  | and also  contrary to common sense.

But I have a harder time following this.

  | Contrary to common sense in that, adding 
  | memberships to other sockets (in other processes) should not to be able 
  | to cause a multicast socket to receive packets it didn't ask to 
  | receive.

That's fine.

However, you're making an assumption that the process didn't ask to
receive the packets.   Unless you're talking about link scope multicast
addresses (or similar) - which I don't think were what your PR used as
an example, and certainly weren't in your proposed patch, shouldn't a
packet transmitted to a particular multicast address go everywhere?
What difference does it make which interface happens to have been used
(other than to the source address when the application transmits packets,
and hence the forwarding path).

My assumption when I bind to a particular (non limited scope) multicast
address, is that I am going to receive *every* packet sent to (the
correct port) using that multicast address, not some subset of them.

If the issue is just that the "same" packets get delivered on multiple
interfaces, and hence the application gets multiple copies (which I don't
think is really what you're concerned about, but just in case) then I
believe that's simply a fact of multicast life - packets can be
delivered more than once.

What process or application is actually depending upon different
applications running on the same address and port, but binding to
different interfaces, actually receiving different sets of packets,
on something that isn't a limited scope address?

kre