Don,
I don't have a current copy of UNP, so I'm operating blind here. But,
if I understand correctly, if I have a process with a socket bound to
INADDR_ANY:9462 and some other process joins, say, 239.0.0.1, then without
your patch, packets sent to 239.0.0.1:9462 will be delivered, and with your
patch they will not be delivered. Is that correct?
If so, a literal reading of RFC 1112 suggests that multicast packets
should be treated like any other local addresses. And INADDR_ANY should
match any local addresses, so that would imply that any unicast, broadcast
or multicast packet delivered to a host that has that address configured
should be delivered.
I don't see any huge problem with limiting delivery to sockets that
have actually joined the group, as long as that doesn't require the socket
be bound to the particular multicast address (if I bind to INADDR_ANY:9462
and join a group, I should definitely still receive multicasts on my
INADDR_ANY socket).
But I also don't see any advantage. It limits admittedly trivial and
not-very-useful things, like sending a UDP "time" request to the NTP
multicast address, or anything else where you're requesting service on a
host identified by membership in a group not associated with that service.
(for example, any UDP service to the "all routers" group) I do this sort of
thing all the time "ping" to identify routers, NTP servers, etc. ; maybe
other applications using UDP might also find that useful.
Is the goal of your patch BSD compatibility, or is there some problem
this causes? I think it's better that multicasts identify a set of
machines, and filtering for services be left to the port (only). I think
that's the intent of RFC 1112, whether or not BSD took it further.
+-DLS
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
This archive was generated by hypermail 2b29 : Fri Nov 15 2002 - 22:00:00 EST