Task #2053
closed
Strategy choice in config file
100%
Description
Initial configuration of strategies is extremely important operation. I have seen so many reports on the mailing list of improper strategy settings, which will be non-existent if only we had initial default settings in the config file.
This task is to add an option in the configuration file to configure strategies for namespaces. This will duplicate strategy management protocol, but both of them serve different purposes---one initial config and the other runtime configuration.
Updated by Anonymous about 10 years ago
- Assignee set to Anonymous
nfd.conf currently defines a "tables" section with the following comment: "The tables section configures the CS, PIT, FIB, Strategy Choice, and Measurements tables". Should this task be implemented as a "strategy" subsection that represents Strategy Choice and lists (prefix, strategy name) pairs?
Example:
tables
{
cs_max_packets 65536
strategy
{
/ /localhost/nfd/strategy/ncc
/foo /localhost/nfd/strategy/bestroute
}
}
Updated by Alex Afanasyev about 10 years ago
Yeah. I like this. Would this be ok for the INFO format parser?
Updated by Junxiao Shi about 10 years ago
- Subject changed from Add (duplicate) strategy configuration in config file to Strategy choice in config file
tables section contains characteristics of tables, such as size limit and replacement policy.
Strategy choice is the contents of a table, which needs its own section:
strategy_choices {
/ /localhost/nfd/strategy/best-route
/ndn /localhost/nfd/strategy/ncc
/ndn/broadcast /localhost/nfd/strategy/broadcast
}
When management module processes the configuration, conceptually it should start retrieving the strategy code (remember that strategies could be written in a scripting language and need to be retrieved), and set strategy choice once strategy code is retrieved.
daemon/fw/available-strategies.cpp should still set a default strategy, which will take effect before strategy retrieval is complete.
Updated by Anonymous about 10 years ago
I think it's confusing to have one section (tables) to configure one aspect of a table and another (counter-proposed strategy_choice in note-3) to configure others. Ideally, there should be a single place for configuring all aspects of a table and I think having strategy_choice as a subsection of tables is the best way in the current config format.
However, this task describes something that was not intended when we first added the tables section. Does it make more sense to get rid of tables entirely and give each table its own config section?
Updated by Junxiao Shi about 10 years ago
I agree with note-4 that strategy_choices can be a subsection of tables.
Don't get rid of tables and create one section per table.
We have face_system section for all faces, so we can have tables for all tables.
Updated by Junxiao Shi about 10 years ago
- Start date deleted (
10/12/2014) - Estimated time set to 9.00 h
Remember to update NFD Developer Guide with the changes, as part of this Task.
Updated by Anonymous about 10 years ago
- Status changed from New to Code review
- % Done changed from 0 to 100
Updated by Anonymous about 10 years ago
- % Done changed from 100 to 80
Still need to update developer guide.
Updated by Anonymous about 10 years ago
- % Done changed from 80 to 100
Updated the developer guide (just a small addition). I did not update the guide's revision history.
I'll close this task if there's no response/request for changes in 24 hours or so.
Updated by Anonymous about 10 years ago
- Status changed from Code review to Closed