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
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
