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 17:19:14 -0400 [thread overview]
Message-ID: <49E7A0D2.60504@hp.com> (raw)
In-Reply-To: <OF0F292ED0.17C084A6-ON8825759A.00718BFC-8825759A.00730FD8@us.ibm.com>
David Stevens wrote:
>> Well guess then we need the global proc setting after all. With the
>> current misbehavior as a default applications need to be rebuilt and
>
> The current behavior, as either your or Vlad's RFC quotes pointed
> out as easily as the history to go with it, is exactly the expected behavior
> for decades. I think it is not misbehavior so much as your misconception,
> though a common one.
>
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.
>> source code that is running on multiple OSes now would have to customized
>> to special case for Linux.
>
> No, actually. If you write it for the current behavior, it'll work
> fine on an OS like Solaris that has departed from the original socket
> behavior. If you're sloppy and don't handle unexpected traffic, it'll be
> wrong on both-- you just won't know it until someone runs something with
> the same port and multicast address on your network and wrecks your app.
I'd have to reluctantly agree here. Any application that expects original
multicast behavior will be broken by a system-wide change. I think existing
applications have already figured out all the workarounds they need.
>
>> So add a global proc setting to determine the initial setting of
> IP_MULTICAST_ALL?
>
> This breaks unknown existing applications that are correctly
> written. I think it's clearly wrong to change the behavior of someone
> else's socket to match your idea of how it should've been done 25 years
> too late. An option that enables new behavior for your own socket, which
> must be a new app, is fine. Adding a socket option as part of a port
> is no great hurdle, and I'm guessing you aren't trying to run a Solaris
> binary on Linux. So what's the problem?
>
> +-DLS
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.
-vlad
next prev parent reply other threads:[~2009-04-16 21:19 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 [this message]
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
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=49E7A0D2.60504@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).