> Is this done that way to allow the same socket to join more than one
> group (hence binding to in6addr_any)?
The short answer is that it's done that way because the inventor
of multicasting and first implementation done on BSD UNIX did it
that way. But the semantics are exactly those of unicast addresses
for sockets, so it also means it doesn't add special processing
for multicasts.
> Yeah, this seems wrong at first glance. For a socket bound to
> in6addr_any, is there no way to simply check if it has joined the group
> to which the packet is destined?
Certainly it is possible, but multicast socket semantics were defined
a long time ago, and this behavior is explicit in multicast RFC's as
well. Changing them on Linux only would only make all programs that
use it non-portable to all other UNIX and Windows systems (and anything
else that supports sockets). The patch I did fixing the behavior from
what you described to the current behavior resulted from a port of a
Java engine that worked on a UNIX system and not on Linux, because it
joined the groups in one process and (correctly) expected to receive
multicasts sent to a different socket in a different process. The patch
Takashi-san referred to was the complementary case where an application
was incorrectly receiving too much, because of that bug.
> multicast packets, for the simple reason that someone is using the same
> port, but for multicast communications. It seems to me that there
> should be some scheme to protect against those cases.
Port binding rules prevent this, at least on the same machine. If both
the group and the port are used by different applications on different
machines on the same network, you could have a problem (and applications
need to make sure they aren't getting garbage, anyway). But there are
both well-known ports and well-known multicast addresses assigned by IANA
exactly to prevent conflicts like this, at least for applications that
have registered them. In that respect, it really is no different from
using unicast addresses.
+-DLS