[prev in list] [next in list] [prev in thread] [next in thread] 

List:       snap-users
Subject:    (KAME-snap 9487) Re: Questions about MSF implementation
From:       Hitoshi Asaeda <asaeda () sfc ! wide ! ad ! jp>
Date:       2006-08-28 12:34:41
Message-ID: 20060828.213441.108738421.asaeda () sfc ! wide ! ad ! jp
[Download RAW message or body]

> 1. In in_setmopt_source_addr() in in_msf.c, when creating a new multicast
> source filter list, why set the "refcount" in the sock_msf_source structure
> as 2 rather than 1? The similar setting is used in in_setmopt_source_list(),
> too. What's the intention of this design?  The caller of
> in_setmopt_source_addr() also calls in_cleanmopt_source_addr() to adjust the
> "refcount" whose original value is 2 as 1. What's the reason to do so?

Similar to the previous answer. It is prepared for an undo procedure
(in_undomopt_source_list()). But it is different from the previous
logic, because this undo procedure also needs to distinguish the MSF
operations.
Regarding MLD_MSFON_OPS operation, if refcount == 2, the failed
operation should have newly added the source address to the socket,
and if refcount == 0, it should've deleted the source address to the
socket. If there is some error, in_undomopt_source_list() recovers
everyting based on the refcount value. If no error,
in_cleanmopt_source_addr() finally adjusted to the correct refcount.
Regarding other operations (e.g. MLD_MSFOFF_OPS), refcount is
normally adjusted (and can be recovered).

> 2. There's one source list called "i6ms_rec" in in6_multi_source structure.
> I'm wondering what it is used for and what the difference is between
> "i6ms_rec" and "i6ms_cur"?

i6ms_cur expresses an interface state.
i6ms_rec keeps a source address list for a pending MLD report.
--
Hitoshi Asaeda
[prev in list] [next in list] [prev in thread] [next in thread]