Re: IGMPv3 implementation

A bit more technical detail, as I may be taking a break quite soon:

    IGMPv3 state changes happen on a group-by-group basis. IGMPv3 state 
change reports, however, are issued on a per-link basis.
    If the state for a group changes, the pending state change is 
computed and enqueued to a per-group state-change queue. This involves 
an RB-tree walk of the source list for the group. Per source counters 
are not used here -- if a state change happens at t1 *before* a new 
report is issued, the group's queue will get blown away and the group's 
state change recomputed.

    In practice the RB-tree should perform reasonably well,.and for most 
use cases, this shouldn't present a problem. If a more scalable solution 
is needed, that's up to the user.

    The igmp_v3_merge_state_changes() function will cherry-pick from the 
group's queue, and bundle it into the outgoing per-link queue. To break 
out from under the locks, a software interrupt is used to actually 
transmit the outgoing state-change report.

    There is always room for improvement, though. The main thrust of the 
project was to get IGMPv3 into the tree in an SMPng compatible way, and 
time was sadly limited.

thanks,
BMS