From: Vlad Yasevich <vladislav.yasevich@hp.com>
To: David Stevens <dlstevens@us.ibm.com>
Cc: Christoph Lameter <cl@linux.com>,
David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, netdev-owner@vger.kernel.org,
Neil Horman <nhorman@tuxdriver.com>
Subject: Re: PATCH: Multicast: Filter multicast traffic per socket mc_list
Date: Thu, 16 Apr 2009 20:01:38 -0400 [thread overview]
Message-ID: <49E7C6E2.8000209@hp.com> (raw)
In-Reply-To: <OF5FEB5C36.3F71F1EC-ON8825759A.00785E5C-8825759A.007AEF72@us.ibm.com>
David Stevens wrote:
> Vlad Yasevich wrote on 04/16/2009 02:19:14 PM:
>
>> What seems to be happening though, is that there is an expectation that
>> this behavior would change with advent of IGMPv3, which adds the
> additional
>> filtering text. Now, we could point out that there is no normative text
>> that requires this filtering on groups, only on sources, but the
> expectation
>> is still there.
>
> I have no such expectation. :-) The additional filters are
> (already)
> applied per-socket, but existing apps not using source filters behave as
> they did before IGMPv3. That's what I'd expect.
> The RFC you quoted for SSM applies to only the SSM address space,
> mentions this behavior explicitly as the norm for outside of that space,
> and Linux doesn't support that RFC. If it did, it would include an
> address range check as part of it.
Yes, after reading more of SSM spec, it definitely only applies to SSM
addresses that we don't support yet. Just to clear this one item up,
I think the expectation comes from the IGMPv3 spec:
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.
I could be inferred from this rather vague text that in addition to source
filtering, group filters should be done. Thus the expectation that we've
been dealing with.
That's the last I'll mention this, since most salient points have been
agreed on.
Thanks
-vlad
>
>> I wonder how BSD and Solaris got away with it? They both filter on
> multicast
>> groups and source addresses. This is not meant as rhetorical or
> provocative,
>> just genuinely wondering.
>
> I think in practice, it doesn't come up much. That's why people
> seem so surprised to learn it works this way, and not the way they
> thought it did after using it, sometimes for years. But the documentation
> doesn't say a join limits what you receive on a socket, or that it
> has to be the same socket you're doing I/O on; people simply assume it.
>
> +-DLS
>
next prev parent reply other threads:[~2009-04-17 0:01 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-16 14:38 PATCH: Multicast: Filter multicast traffic per socket mc_list Christoph Lameter
2009-04-16 15:09 ` David Stevens
2009-04-16 15:36 ` Christoph Lameter
2009-04-16 22:15 ` David Miller
2009-04-16 15:15 ` Neil Horman
2009-04-16 15:36 ` Christoph Lameter
2009-04-16 17:44 ` Neil Horman
2009-04-16 19:12 ` Christoph Lameter
2009-04-16 20:56 ` David Stevens
2009-04-16 21:04 ` Christoph Lameter
2009-04-16 21:54 ` David Stevens
2009-04-16 22:19 ` David Miller
2009-04-16 21:19 ` Vlad Yasevich
2009-04-16 22:20 ` David Miller
2009-04-16 22:22 ` David Stevens
2009-04-16 23:30 ` Stephen Hemminger
2009-04-17 0:01 ` Vlad Yasevich [this message]
2009-04-16 22:16 ` David Miller
2009-04-17 13:56 ` Christoph Lameter
2009-04-17 15:37 ` Nivedita Singhvi
2009-04-17 16:02 ` Christoph Lameter
2009-04-17 16:28 ` Nivedita Singhvi
2009-04-17 22:24 ` David Miller
2009-04-20 18:10 ` Christoph Lameter
2009-04-17 21:31 ` David Stevens
2009-04-20 16:43 ` Christoph Lameter
2009-04-20 18:46 ` David Stevens
2009-04-16 15:24 ` Vlad Yasevich
2009-04-16 15:39 ` 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=49E7C6E2.8000209@hp.com \
--to=vladislav.yasevich@hp.com \
--cc=cl@linux.com \
--cc=davem@davemloft.net \
--cc=dlstevens@us.ibm.com \
--cc=netdev-owner@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).