[Nfd-dev] strategy specific parameters

[Klaus Schneider]

Here is my quick and dirty solution for including parameters in the 
strategy name.

1. I added a string variable to the strategy.hpp class (+ getters and 
setters):

> protected std::string parameters;

>   public void setParameters(std::string newParameters){
>     parameters = newParameters;
>   }
>
>   public const std::string getParameters(){
>     return parameters;
>   }

2. I changed StrategyChoice::getStrategy() in strategy-choice.cpp to

> fw::Strategy*
> StrategyChoice::getStrategy(const Name& strategyName) const
> {
>   fw::Strategy* candidate = nullptr;
>   for (auto n : m_strategyInstances) {
>     if (strategyName.isPrefixOf(n.first) || n.first.isPrefixOf(strategyName)) {
>       switch (n.first.size() + 1 - strategyName.size()) {
>       case 0: // Strategy with parameters (one element longer than exact match)
>         n.second->setParameters(strategyName.toUri().erase(0, n.first.toUri().size() + 1));
>         return n.second.get();
>       case 1:  // exact match
>         return n.second.get();
>       case 2:  // unversioned strategyName matches versioned strategy
>         candidate = n.second.get();
>         break;
>       }
>     }
>   }
>   return candidate;
> }

3. Since one can't access the parameters in the constructor (they are 
set later), I created a method inside my strategy that is called once 
after the first call of afterReceiveInterest():

> void YourStrategyName::initialize()
> {
>   if (!init) {
>     init = true;
>     std::cout << "Parameters: " << parameters << "\n";
>
>     // Use parameters
>     double value = std::stod(parameters);
>     setParameters(Type::LOSS, value);
>   }
> }

Seems to work fine and saves a lot of recompilation time when using 
ndnSim. Just set the desired parameters after the full strategy name (as 
Alexander suggested in a previous mail):

>   ndn::StrategyChoiceHelper::Install(client, "/",
>       "/localhost/nfd/strategy/your-strategy/%FD%01/0.4");

Of course, one could add separated key-value pairs and define a syntax 
for that.

Best regards
Klaus



On 14.04.2015 22:59, Klaus Schneider wrote:
> Hi Junxiao and Alex,
>
> Thank you for your elaborate answer. Using parameters as part of the
> strategy name is an interesting concept.
>
>> Another way of specializing strategies is to define a parameters as
>> part of strategy name.  For example,
>>
>> ndn:/localhost/nfd/strategy/broadcast/%FD%01/?param=false
>>
>
> Is it possible to access this parameter inside the strategy when using
> ndnSim?
>
> In my simulation file I added a parameter:
>
>> ndn::StrategyChoiceHelper::Install(client, "/",
>>       "/localhost/nfd/strategy/somestrategy/%FD%01/?param=true");
>
> However, none of the following two variables shows the correct parameter
> inside the strategy constructor:
>
>> StrategyChoice& strategyChoice = forwarder.getStrategyChoice();
>>   Strategy& str = strategyChoice.findEffectiveStrategy("/");
>>
>>   std::cout << "Name: " << str.getName() << ", " << name << "\n";
>
> Is there another way to access the parameter?
>
> Regarding the duplicate nonce loops: I think this is not a problem when
> the client who uses the broadcast strategy is not a source for the
> requested content. If no routes go back to the client (which is the
> scenario I had in mind), then to my understanding the Interest packets
> can't loop.
>
> Even if this won't get implemented, I think it's a good example how
> parameters can help to avoid creating a new strategy for a change of one
> line of code.
>
> Thanks,
> Klaus
>
>
>
>
>
> On 14.04.2015 01:10, Junxiao Shi wrote:
>> Hi Klaus
>>
>> 20150413 conference call discussed this proposal.
>>
>> This proposal is a subset of #2000 composable strategy building blocks
>> <http://redmine.named-data.net/issues/2000>.
>> With #2000, an operator can not only pass parameters to a strategy, but
>> also create new strategies. Both can happen at runtime.
>> Passing parameters is just a special case of creating new strategies:
>> take
>> an existing strategy, and give it new parameters.
>>
>>
>> I believe having strategy parameters is a good direction toward #2000.
>> I agree with Alex that parameters should be carried in the Name after the
>> version component, at the management protocol
>> <http://redmine.named-data.net/projects/nfd/wiki/StrategyChoice> level.
>> At command line tool level, however, I prefer to accept ccndc syntax as
>> well: operator can either specify parameters as part of the strategy
>> Name,
>> or in separate command line options.
>>
>>
>> I disagree with the use case that broadcast strategy generates new Nonces
>> for outgoing Interests, because it can cause persistent Interest loop
>> in #1953
>> scenario <http://redmine.named-data.net/issues/1953>.
>>
>> Yours, Junxiao
>>
>> On Sun, Apr 12, 2015 at 6:23 AM, Klaus Schneider <
>> klaus.schneider at uni-bamberg.de> wrote:
>>
>>> Hi everyone,
>>>
>>> I think it would be a good idea to have (optional) parameters for a
>>> forwarding strategy in order to make the design more flexible.
>>>
>>> The CCNx prototype supports this:
>>>
>>>   ccndc setstrategy <prefix> <strategy> [<parameters> [<lifetime>]]
>>>>
>>>
>>> Unfortunately, there is currently no such option in NFD:
>>>
>>>   nfdc set-strategy <namespace> <strategy-name>
>>>>
>>>
>>>
>>> If you think this is reasonable, I can help with the implementation.
>>> I am
>>> also not sure if this is the right place for such feature requests or
>>> if I
>>> should put them up as a redmine ticket?
>>>
>>> Thanks,
>>> Klaus
>>
>

-- 
Klaus Schneider

Mail: klaus.schneider at uni-bamberg.de
LinkedIn: https://www.linkedin.com/in/schneiderklaus