From: Vlad Yasevich <vladislav.yasevich@hp.com>
To: Christoph Lameter <cl@linux.com>
Cc: Neil Horman <nhorman@tuxdriver.com>,
netdev@vger.kernel.org, David Miller <davem@davemloft.net>,
David Stevens <dlstevens@us.ibm.com>
Subject: Re: [PATCH] Multicast: Avoid useless duplication of multicast messages
Date: Wed, 15 Apr 2009 17:06:47 -0400 [thread overview]
Message-ID: <49E64C67.90201@hp.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0904151516380.18317@qirst.com>
Christoph Lameter wrote:
> On Wed, 15 Apr 2009, Vlad Yasevich wrote:
>
>> Looking at BSD, which was the root of the original brokeness, they have it fixed.
>> The code will skip sockets that are not members of a particular group. So, we
>> are trying really hard to stay bug-for-bug compatible with old implementations.
>
> Ahh interesting. David: Could you say something on this?
Just digging around some more, it appears that OpenSolaris also filters out
non-joined groups at the socket:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/inet/ip/ip_multi.c#ilg_lookup_ill_withsrc
In that code, connp is essentially a socket and ilg is the membership list.
That function function called from conn_wantpacket(), which is in turn called
for every socket that matches the packet.
>
>> What's worse is that if you have a socket that doesn't care about any mulicast
>> destinations (never did an ADD_MEMBERSHIP), it will still get multicast traffic if
>> it bound to that port.
>>
>> We need to take into account the socket's multicast group list.
>
> Right. The fix is pretty simple too since the infrastructure has been
> there since the IGMPv3 updates.
>
Right. since IGMPv3 introduced the concept of filtering. It even states this
in RFC 3376:
Filtering of packets based upon a socket's multicast reception
state is a new feature of this service interface. The previous
service interface [RFC1112] described no filtering based upon
multicast join state; rather, a join on a socket simply caused the
host to join a group on the given interface, and packets destined
for that group could be delivered to all sockets whether they had
joined or not.
-vlad
next prev parent reply other threads:[~2009-04-15 21:06 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-13 21:06 Kernel sends multicast groups to sockets that did not subscribe to the MC group Christoph Lameter
2009-04-14 13:25 ` Neil Horman
2009-04-14 13:53 ` Christoph Lameter
2009-04-14 18:27 ` Neil Horman
2009-04-14 18:33 ` Christoph Lameter
2009-04-14 20:01 ` Neil Horman
2009-04-14 20:16 ` Christoph Lameter
2009-04-14 18:48 ` [PATCH] Multicast: Avoid useless duplication of multicast messages Christoph Lameter
2009-04-14 20:44 ` Neil Horman
2009-04-14 21:45 ` Christoph Lameter
2009-04-15 11:07 ` Neil Horman
2009-04-15 12:51 ` Christoph Lameter
2009-04-15 14:22 ` Neil Horman
2009-04-15 14:41 ` Vlad Yasevich
2009-04-15 15:57 ` Neil Horman
2009-04-15 16:07 ` Vlad Yasevich
2009-04-15 16:38 ` Neil Horman
2009-04-15 17:19 ` Vlad Yasevich
2009-04-15 17:53 ` Neil Horman
2009-04-15 19:21 ` Christoph Lameter
2009-04-15 19:43 ` Neil Horman
2009-04-15 19:17 ` Christoph Lameter
2009-04-15 21:06 ` Vlad Yasevich [this message]
2009-04-15 23:45 ` David Miller
2009-04-16 12:44 ` Vlad Yasevich
2009-04-15 21:42 ` David Stevens
2009-04-15 22:16 ` David Stevens
2009-04-16 14:45 ` Christoph Lameter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49E64C67.90201@hp.com \
--to=vladislav.yasevich@hp.com \
--cc=cl@linux.com \
--cc=davem@davemloft.net \
--cc=dlstevens@us.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.