Project

General

Profile

Actions
Copy link

Bug #2720

open

Face::unsetInterestFilter is ineffective before registration completes

Added by Junxiao Shi over 9 years ago. Updated over 9 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Base
Target version:
-
Start date:
04/01/2015
Due date:
% Done:

0%

Estimated time:

Description

Snippet to reproduce:

// g++ -std=c++0x x.cpp $(pkg-config --cflags --libs libndn-cxx)
#include <ndn-cxx/face.hpp>

using namespace ndn;

int
main()
{
  Face face;

  const RegisteredPrefixId* id = face.setInterestFilter("/A",
    [=] (const Name&, const Interest& interest) {
      std::cout << interest << std::endl;
    },
    [=] (const Name&) {
      std::cout << "DONE" << std::endl;
    },
    [=] (const Name&, const std::string&) {
      std::cout << "FAIL" << std::endl;
    });

  face.unsetInterestFilter(id);

  face.processEvents();

  return 0;
}
  1. call Face::setInterestFilter to register a prefix
  2. before the registration completes, call Face::unsetInterestFilter to undo the registration

Expected: after both operations, prefix registration does not exist

Actual: prefix registration still exists in both NFD and ndn::Face

Actions
Copy link
 #1

Updated by Joao Pereira over 9 years ago

This issue I believe it should be expected because we are working with async operations, so if they are related the caller should be sure that they are only scheduled when they will be effective.

Or the idea behind this bug is to make some sort of Queue of operations over interest filter?

Actions
Copy link
 #2

Updated by Junxiao Shi over 9 years ago

It's wrong to complete unsetInterestFilter without exception if this operation is not supported before prefix registration is complete.

Possible fix 1:

  1. after setInterestFilter but before prefix registration is complete, calling unsetInterestFilter shall throw an exception indicating the InterestFilter is not in the correct state.

Possible fix 2:

  1. after setInterestFilter but before prefix registration is complete, calling unsetInterestFilter sets a "undoAfterRegistration" flag on the InterestFilter.
  2. when prefix registration is complete, if the "undoAfterRegistration" flag is set, immediately unset the InterestFilter and initiate prefix unregistration.
Actions
Copy link
 #3

Updated by Joao Pereira over 9 years ago

I believe that the second approach is more interesting because it abstracts the user of this async behaviour. But the second one gives more controller to the developer of the application.

But for the second approach what should happen when the setInterestFilter is called with the undo flag?

  1. Post the unsetInterestFilter operation
  2. Not add the filter to the table
Actions
Copy link
 #4

Updated by Junxiao Shi over 9 years ago

Answer to note-3:

In note-2 possible fix 2, "undoAfterRegistration" is an implementation detail. It is not part of public API. It's an assertion error if someone invokes setInterestFilter with "undoAfterRegistration" set.

Actions
Copy link
 #5

Updated by Joao Pereira over 9 years ago

Implementation details for the 2 possible fixes in note-2

If we implement note-2 fix 1:

. Block this issue until http://redmine.named-data.net/issues/2658 is solved

. Change Face::Impl::asyncUnsetInterestFilter

  1. If the filter is not set call onFailure function

===

If we implement note-2 fix 2:

. Add field bool InterestFilter::undoAfterRegistration with setter and getter

. Change on Face::Impl::registerPrefix

  1. If InterestFilter::undoAfterRegistration is true call error callback

. Change on Face::Impl::asyncUnregisterPrefix

  1. If register do not exist set InterestFilter::undoAfterRegistration to true and call error callback
Actions
Copy link

Also available in: Atom PDF