[ndnSIM] CS management - doAfterInsert in Policy

[Junxiao Shi]

Hi John

3.  If (1) and (2) are accurate, consider a situation where the CS is *full*.
> When a data packet arrives, will doAfterInsert still be called?  Will an
> item in the content store be removed arbitrarily?  The reason I ask is
> because if doAfterInsert is called *after *the data packet has been added
> to the CS, then we're too late, right?  Something has been booted in order
> to make room.  But shouldn't we get to decide *before *the item is
> added?  How is this handled?
>

If CS capacity is 1000 and already has 1000 entries,

   1. Cs::add will insert the entry. At this moment, CS contains 1001
   entries.
   2. cs::policy::doAfterInsert is invoked. It SHOULD evict at least one
   entry.
   3. When Cs:add returns, CS contains no more than 1000 entries.


I designed it this way, to save an invocation to the policy.
The alternative would be invoking the policy twice: once before inserting
an entry to decide whether to accept the new entry and to make room if
necessary, and once after inserting the entry to record the entry in the
cleanup index.

The current insert-then-evict procedure is more efficient because the
policy is invoked only once. This allows the policy to reuse internal
variables when feasible. Although the CS can contain more entries than its
"capacity", the final outcome (when Cs::add returns) is correct.
Temporarily storing more entries than "capacity" during the execution of
Cs::add is entirely an implementation detail because it is not observable
from outside, given that the Cs class is not thread-safe so no other
methods can be called until Cs::add returns.
Also, the "capacity" is enforced by the policy; the Cs class does not care
about capacity. You can even make a policy that does nothing, in which case
the CS will grow continously until NFD crashes due to out-of-memory.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20170604/2c4178c0/attachment.html>