Re: multicast group memberships purge on interface delete

[jamal <hadi@cyberus.ca>]

On Wed, 2006-23-08 at 15:29 +0200, Michal Růžička wrote:

> 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.
> 

Ok - Same effect. i.e the same events would be generated if a gre
dissapears or an ethernet is rmmoded.

> > 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.

How would they know that the interface has been deleted?
If you have the answer to that, then why dont you do the
unsubscriptions/leaves as well?

> (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.)
> 

Right. So does your app do this?

> 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?

An arguement can be made that if you joined the groups from the app,
then the app should be responsible to unsubscribe. i.e this is a policy
decision. 
You could have the kernel implement your policy as you described, but in
my view you would have to tell it. And conditional compilation or some
way of telling the kernel would fit in such a case.
There is probably a good reason why NetBSD insists on doing it in the
kernel; do you know what this reason is?

cheers,
jamal