(usagi-users 03626) Re: IPv6 multicast socket specific binding bug

[David Stevens <dlstevens@xxxxxxxxxx>]

Hugo Santos <hsantos@xxxxxxxx> wrote on 03/17/2006 11:00:09 AM:

> David,
> 
>    I'm sorry if my line of thought is wrong, but, considering that in
>  Hoerdt's example, the S1 socket didn't join the group, shouldn't it's
>  multicast filter implicitly be INCLUDE {} for all groups? Is the socket
>  filter only considered for MLDv2 Reports and not for packet delivery?

        Well, no. I mean, you're assuming that the join has something to
do with what packets are delivered to the socket the join was done on
first, and then wondering why joins aren't per-socket. :-)
        A join of a group on a machine was never defined to affect just
one socket, and has never had anything to do with what socket you did
the join on. You can join every group (for the whole machine) on a
socket that you never do any I/O on. The socket doesn't even have to
be the same protocol as the sockets you're doing I/O on! For example,
you can join all groups the machine needs on a raw ICMP socket, and
do all the I/O for those groups on UDP sockets.

        I understand that this confuses a lot of people, but it isn't
a reasonable argument to assume one model first, and then consider it
a bug that the code follows a different model. :-)
        The RFC, the original socket implementation, and all others
after, use the model that packet delivery to a socket is determined
by the address & port binding (i.e., the bind() call). Delivery to
the machine is determined by unicast, broadcast and multicast
addresses associated with the interfaces. Multicast joins don't
change that at all-- they follow the same model as unicast and
broadcast did before IP multicasting existed.

        You could make the same case that you should be able to bind()
to a unicast address not on the local machine and then receive any
packets on that network for that non-local unicast address. That's
an alternative, and reasonable model, but it isn't how sockets were
defined. Maybe you want to define a new API that aren't sockets. :-)

        But whether you agree with the way it was originally designed
or not, it isn't something new and changing the behavior to fit a
different model on Linux only simply would break existing applications
for Linux that use the existing model, and make anything using that
on other OSes no longer portable to Linux.

                                                        +-DLS