NFD

I suggest to have a NameTree::deleteIfEmpty(name_tree::entry& entry) method which deletes the entry if there is nothing attached and there is no children.

I have added the function deleteNPEIfEmpty(NamePrefixEntry * npe) to the NameTree, which deletes npe if it is empty, and it also follows the parent pointers to remove qualified parent NPE(s).

So currently to delete a PIT/FIB/Measurement, the following steps need to be performed

• Lookup the name prefix and get the corresponding NPE via npe = nt->lookup(name)

• Delete the corresponding fields via npe->deletePIT/FIB/Measurement(PIT/FIB/Measurement)

• Explicitly call the nt->deleteNPEIfEmpty(npe) to clean the empty NPE.

We could add APIs. such as deletePIT, deleteFIB, to the Name Tree if the above three steps are tedious.

It's fine to have all necessary steps inside Pit::remove method.
The caller (forwarding) only needs to call Pit::remove.

Got it. The other thing is do we want to have an Interest table (like CCNx does), which is indexed by the Interest (or full name, i.e., Name + selectors), and each hash bucket stores a pointer to the corresponding PIT Entry. Alternatively, the PIT lookup will be:

• Lookup PIT Interest's Name in Name Tree (just 1 hash lookup with the full name without selectors), and get its Name Tree Entry

• Get the list of PIT Interests from the Name Tree Entry and then compare and find the PIT Entry being queried.

This is a trade-off between memory and lookup efficiency.

I think there won’t be lots of Interests with same Name but different Selectors, so I prefer not to have an Interest table.

Ultimately it’s assignee’s decision.

Sure, I think we could leave this issue open for now, and consider it as an optimization option.

Is the mock design for PIT/FIB/Measurement complete (i.e., could forward packets correctly)? If so, I would suggest to keep both the name-tree based implementation and the mock design in each PIT/FIB/Measurement function.

In each function, the results from these two implementations should be compared before it is returned. This way, we would be able to detect the bugs in the code easily. After the code becomes stable, we could remove the mock design code.

What do you think?

Mock implementations are incomplete, and incorrect in some cases.

NameTree based implementation SHOULD replace mock implementations.

Correctness is guaranteed by unit testing.
Use caution when you need to modify or remove an existing test case.

Will InRecord and OutRecord be updated per packet? And when will they be modified? An example with Interest or Data packet will be really helpful. Thanks.

InRecord is updated in incoming Interest pipeline. OutRecord is updated in outgoing Interest pipeline. Both are updated per packet.

This task should not change any public fields of pit::Entry.

This task can add a pointer to name_tree::Entry inside pit::Entry, but such field shall be private, and NameTree can be made a friend.

So should the nonce value be checked for each Interest packet (in the insert function? )? or there are functions in other parts of the project that handles it.

If it is the first case, then the return value of the Pit::insert() function will need to be changed to cover the case that there is a nonce match.

Pit::insert should create pit::Entry according to Interest Name and Selectors. It should not add InRecord, and should not look at Nonce.

Another question about the pit::remove(shared_ptrpit::Entry) function:

• Currently, to get the NameTree Entry (which implements the deletePitEntry() function), we need to get the given pit::Entry's name, and then perform a lookup on NameTree first. The reason is that the PIT Entry doesn't keep a pointer to the NameTree Entry. I am wondering if the future work will add some pointer there (such as Task #1202: shortcuts between FIB, PIT, Measurements), or it could be added now, i.e., a pointer to its NameTree Entry.

• Currently, there is no return value for remove(), so is it guaranteed that the pit::Entry in the argument is always a valid one?

Just to add another question, in the PIT mock design, it seems that findAllDataMatches compares only Names, and Interest selectors are not used. Should we do the same thing for the NameTree-based coding?

Mock design:

  shared_ptr<pit::DataMatchResult> result = make_shared<pit::DataMatchResult>();

  for (std::list<shared_ptr<pit::Entry> >::const_iterator it = m_table.begin();
       it != m_table.end(); ++it) {
    shared_ptr<pit::Entry> entry = *it;
    if (entry->getInterest().matchesName(data.getName())) {
      result->push_back(entry);
    }
  }
  return result;

If you find it more convenient to work on #1202 concurrently, I have no objection. Suggested API is put in #1202.

Pit::remove should be renamed to Pit::erase per CodeStyle amended rule 26.
The argument must be valid, but you don't have to check whether it exists in PIT.

Interest::matchesName can process Selectors, but it cannot handle implicit digest correctly.

ndn-cpp-dev Bug #1298, when resolved, shall contain necessary functions to help implict digest handling here.