Darren Reed writes:
> James Carlson wrote:
> >Do the clients using this interface need to know the difference
> >between multicast and broadcast in order to function correctly?
> >
> >
>
> No.
So, then, why distinguish?
It looks like you're trying to emulate the BSD {MSG,M}_[BM]CAST flags,
but I'm unsure why that's a useful thing when the emulation (as
defined) doesn't work, it seems like there's no plan to make it work,
and the consumers don't need to know that information anyway.
I'm suggesting that perhaps it'd be worthwhile to make it work or to
consider getting rid of it.
For what it's worth, I care about this because it seems like there's a
plan to make this interface open to projects other than IP Filter. As
just a private interface, the change probably falls below the radar.
> >If so, then why not have this interface resolve the amibiguity? That
> >can be done by checking the destination address (dl_dest_addr_*) when
> >you see that dl_group_address is set.
> >
> >
>
> Even if they did, once the packet reaches IP, it's beyond the
> scope of IP to determine what the MAC destination address
> meant at the MAC layer.
I don't think that's the point. The point is what sort of
functionality makes sense for users of this interface. What gyrations
IP may need to go through to provide the needed information are a
separate design and implementation matter (and I don't think I share
the concern about "scope" -- our IP _implementation_ is already hip
deep in MAC layer trivia, and doing a compare between dl_dest_addr_*
and dl_brdcst_addr_*, to both of which IP has ready access, shouldn't
be hard).
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
