Re: multicast group memberships purge on interface delete

["Michal Růžička" <michal.ruzicka@comstar.cz>]

>
> You should be able to "fix it" in the kernel by listening to events of
> the interface/device disappearing.

Interesting, I've thought that it would have to be done explicitly by the 
interface
cleanup code, this approach looks promising to me.

> By "disappearing" i think you meant
> the netdevice was totally rmmod-ed?

No need to rmmod anything, just think of ppp or gre interfaces which come 
and go
without any modules loading/unloading. But yes, the rmmod would probably be
needed in case of, for example, an ethernet device.

> The challenge is to make the app
> also aware of you taking away the group from underneath them (thats why
> i said "fix it")
>

I dont's see this as any challange as the applications could just assume 
that any
memberships on deleted interfaces have been just droped implicitly by the 
kernel.
(This should be no problem for them provided that they keep track of
the interfaces present on the system, which they should anyway or otherwise
they could end up listening to just a part of the multicast traffic they are
interested in.)

>
> These events are also available in user space via netlink. so an alter
> your app could listen to them and make the group leaves instead of the
> kernel.
>

In fact I've had proposed that on the application mailing list (the 
appliaction is
quagga formerly zebra routing suite to be specific) but the people there 
disliked
it because of the fact that for example the NetBSD (as I noted in my 
previous
post) does the group leaves implicitly on the interface delete and the 
explicit
group leaves fail there (and reportedly on other OSes too).
Sure this can solved by some conditional compilation.
This is why my post was more a theoretical design question/suggestion than
a feature request (or a bug report).

In this sense what do you think about the possible benefit of the proposed
approach for maintaning the per-interface multicast reception state?

> cheers,
> jamal
>

Thanks
Michal