Project

General

Profile

Actions

Task #1202

closed

shortcuts between FIB, PIT, Measurements, StrategyChoice

Added by Junxiao Shi about 10 years ago. Updated about 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Tables
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
6.00 h

Description

Add shortcuts between conceptual tables backed by NameTree.

API

  • Fib::findLongestPrefixMatch(const pit::Entry&)
  • Fib::findLongestPrefixMatch(const measurements::Entry&)
  • StrategyChoice::findEffectiveStrategy(const pit::Entry&)
  • Measurements::get(const pit:*Entry&)

Design

  • xx::Entry needs to declare in "private:" section:

    shared_ptr<name_tree::Entry> m_nameTreeEntry;
    friend class NameTree;
    friend class name_tree::Entry;
    
  • name_tree::Entry methods should set m_nameTreeEntry member when xx::Entry is attached, and unset when xx::Entry is detached (don’t forget to unset on the old attached xx::Entry when attaching a new FIB/Measurements/StrategyChoice entry)

  • NameTree::get(const xx::Entry&) const returns m_nameTreeEntry. This is called by Fib::findLongestPrefixMatch(const pit::Entry&) and other methods, so Fib/etc needn’t be made friends of pit::Entry.

  • Implement Fib::findLongestPrefixMatch overload, etc, by going through the NameTree entries.


Related issues 4 (0 open4 closed)

Blocked by NFD - Task #1190: FIB on NameTreeClosedTian Song

Actions
Blocked by NFD - Task #1194: PIT on NameTreeClosedHaowei Yuan

Actions
Blocked by NFD - Task #1196: Measurements tableClosedTian Song02/17/2014

Actions
Follows NFD - Task #1187: NameTreeClosedHaowei Yuan

Actions
Actions #1

Updated by Junxiao Shi about 10 years ago

  • Due date deleted (02/19/2014)
  • Start date deleted (02/19/2014)
Actions #2

Updated by Junxiao Shi about 10 years ago

FIB/PIT/Measurements entry should contain shared_ptr<NameTree>.

I suggest an API like:

namespace name_tree {
class Entry;
}
namespace fib {
class Entry {
private:
  shared_ptr<name_tree::Entry> m_nameTreeNode;
  friend class NameTree;
};
}
namespace pit {
class Entry {
private:
  shared_ptr<name_tree::Entry> m_nameTreeNode;
  friend class NameTree;
};
}
namespace measurements {
class Entry {
private:
  shared_ptr<name_tree::Entry> m_nameTreeNode;
  friend class NameTree;
};
}
class NameTree
{
  shared_ptr<name_tree::Entry> get(const fib::Entry& fibEntry);
  shared_ptr<name_tree::Entry> get(const pit::Entry& pitEntry);
  shared_ptr<name_tree::Entry> get(const measurements::Entry& measurementsEntry);
};
Actions #3

Updated by Haowei Yuan about 10 years ago

I think the following three functions could be implemented at each fib/pit/measurements-entry.hpp, and probably should not in NameTree class.

  shared_ptr<name_tree::Entry> get(const fib::Entry& fibEntry);
  shared_ptr<name_tree::Entry> get(const pit::Entry& pitEntry);
  shared_ptr<name_tree::Entry> get(const measurements::Entry& measurementsEntry);
Actions #4

Updated by Junxiao Shi about 10 years ago

My idea is, forwarding/strategy should not know about name_tree::Entry. Therefore, it's a private field, and class NameTree is a friend.

Actions #5

Updated by Alex Afanasyev about 10 years ago

Yes, name_tree/NameTree is "internal optimization" that should not be really exposed in the interface, unless there is a very good reason to do so.

Actions #6

Updated by Haowei Yuan about 10 years ago

Yes, the NameTree should not be exposed in the interface to /fw or /strategy.

What I was trying to say is, if the shared_ptr<name_tree::Entry> get(const fib::Entry& fibEntry); is used only internally in fib/pit/measurements.cpp, then it is probably easier to just return fib->m_nameTreeEntry or fib->getNameTreeEntry(), since you already have the fibEntry pointer. (alternatively, you could call m_nameTree->get(fibEntry), which then returns fibEntry->m_nameTreeEntry). It shouldn't matter much in this case...

The nice part of having these three functions in NameTree is that the interface get() is simple and unified.

Actions #7

Updated by Junxiao Shi about 10 years ago

pit::Entry::m_nameTreeEntry is not only used by Pit.

Measurements::get(pit::Entry) would like to get the name_tree::Entry from PIT entry, and follow the pointer to find Measurements entry.

However, it's strange to make class Measurements a friend of pit::Entry, therefore this should go through NameTree::get.

Actions #8

Updated by Junxiao Shi about 10 years ago

  • Subject changed from shortcuts between FIB, PIT, Measurements to shortcuts between FIB, PIT, Measurements, StrategyChoice
  • Description updated (diff)
  • Assignee set to Tian Song
Actions #9

Updated by Tian Song about 10 years ago

  • Status changed from New to In Progress
Actions #10

Updated by Tian Song about 10 years ago

  • % Done changed from 0 to 50
Actions #11

Updated by Tian Song about 10 years ago

  • Status changed from In Progress to Code review
  • % Done changed from 50 to 80
Actions #12

Updated by Tian Song about 10 years ago

  • Status changed from Code review to Closed
  • % Done changed from 80 to 100
Actions

Also available in: Atom PDF