lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0904150841550.10217@qirst.com>
Date:	Wed, 15 Apr 2009 08:51:35 -0400 (EDT)
From:	Christoph Lameter <cl@...ux.com>
To:	Neil Horman <nhorman@...driver.com>
cc:	netdev@...r.kernel.org, David Miller <davem@...emloft.net>
Subject: Re: [PATCH] Multicast: Avoid useless duplication of multicast
 messages

On Wed, 15 Apr 2009, Neil Horman wrote:

> > How are you going to do this?
> I'm going to write each application to use 2 sockets, one bound to each
> multicast group.  Thats the way it works now.  I think you missed the obvious in
> your construction of this example.

Ok it could be done with binding. But you would need 3 sockets. One per MC
groups bound to a MC group each and then one for the replies (hmmm...
looks like you could use SO_BINDTODEVICE on one socket to get around the
third one --there is even an exception case for this in inet_bind causing
more weird semantics-- but then the application needs to know the device
name of the NIC, argh)

> > Its trivial to do with this patch and one
> > socket in each process listening to port 4711 that subscribes to the
> > necessary multicast groups.
> Its trivial without the patch as well.

I do not see how you can justify making such a statement.

> It boils down to this:  This is the way multicast subscriptions have worked in
> bsd, linux, and presumably various other unix and non-unix operating systems for
> lord only knows how long.  Provide some documentation that shows its in
> violation of a newer standard, or that it is common practice to behave
> differently on another OS (such that including this directive would make porting
> easier).  As it stands currently, this patch only serves to create a crutch to
> perpetuate misundersandings about how the behavior currently works.

The way things work is counterintuitive and leads to weird code constructs
with the application having to manage multiple sockets because weird
semantics have developed over the years.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ