Hello there,
I've got the following question/suggestion:

The situation today:
When an interface is deleted and there happen to have been some multicast groups joined on it only the interface's list of multicast meberships is deleted. The sockets through which the groups were joined and more importantly their associated multicast membership lists are left untouched. This makes it difficult for the function that handles leaving multicast groups on a socket to decide what to do with groups that were joined on such an interface (that no longer exists). The present implementation is a kind of a "best guess" (and nothnig better can probably be done about that). It may even fail to leave an affected group (group that was joined on a deleted interface) completely and thus block a slot in the sockets's multicast mebership list which size is purposely limited.

My question/suggestion:
Would it feasible to drop the relevant entries from sockets' multicast membership lists on the interface delete? Yes, I do realize it would require to walk through a number of sockets to see if there is any multicast entry for the interface in question to delete. But this could be optimized by maintaining a list of sockets that have a multicast group joined on the interface (and keep a pointer to this list in the device structure). This would ease the job of the function handling leaving multicast groups, made its beahaviour more "deterministic" and possible errors reported by it more meaningful/reliable.

Notes:
- The suggested approach is reportedly taken by other OSes (notably NetBSD). The fact that linux doesn't behave the same poses a problem for cross platform software for the behaviour
of different systems is different in one more detail.
- The suggested "list of sockets that have a multicast group joined on the interface" could also probably be of some help when maintaining the per interface multicast source filter list or per-interface multicast reception state as per RFC 3376 (IGMPv3) section 3.2.

Thanks
Michal Ruzicka
-
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

Reply via email to