ims_merge in in_mcast.c

[Dheeraj Kandula]

The ims_merge function is invoked only when the imsl_st[0] and imsl_st[1]
are different i.e. a filter mode change. The new filter mode is updated in
ims_st[1].
Thanks for the clarification.

Thanks
Dheeraj

On Tue, Oct 13, 2020 at 9:58 AM Dheeraj Kandula <dkandula at gmail.com> wrote:

> Thanks, HPS for the response. I think the index 0 is for a state (previous
> to current) and 1 indicates the current state. I am still trying to figure
> out what they really mean.  Maybe reading the RFC will shed some light on
> the intention.
>
> My understanding is that the state transition is from index 0 to index 1.
> Hence when we are reverting, the state has to be reverted from index 1 to
> index 0. Isn't it?
>
> For a regular non-rollback scenario, the operation of -1 on line (987 or
> 991) and +1 (997 or 1001) adds up to 0. What are we trying to achieve here?
> Maybe that will help me to understand this code better.
>
> Dheeraj
>
> On Tue, Oct 13, 2020 at 4:18 AM Hans Petter Selasky <hps at selasky.org>
> wrote:
>
>> On 2020-10-12 19:11, Dheeraj Kandula wrote:
>> > On line 987 and 991 shouldn't the index be 0 instead of 1.
>> >
>> > i.e. ims->ims_st[0].ex -= n;
>> > and
>> > ims->ims_st[0].in -= n;
>> >
>> > On a rollback, the entry at index 0 is incremented and the entry at
>> index 1
>> > is decremented.
>> >
>> > On a non-rollback merge, the entry at index 0 is decremented and the
>> entry
>> > at index 1 is incremented.
>>
>> Hi,
>>
>> If you look at inm_commit() you see that [0] is overwritten by [1], so I
>> believe the current code is correct. Same goes for both IPv4 and IPv6.
>> Are you seeing an issue with multicast investigating this issue?
>>
>> --HPS
>>
>