Bug #2720
open
Face::unsetInterestFilter is ineffective before registration completes
Added by Junxiao Shi over 9 years ago.
Updated over 9 years ago.
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;
}
- call
Face::setInterestFilter
to register a prefix
- 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
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?
It's wrong to complete unsetInterestFilter
without exception if this operation is not supported before prefix registration is complete.
Possible fix 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:
- after
setInterestFilter
but before prefix registration is complete, calling unsetInterestFilter
sets a "undoAfterRegistration" flag on the InterestFilter
.
- when prefix registration is complete, if the "undoAfterRegistration" flag is set, immediately unset the InterestFilter and initiate prefix unregistration.
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?
- Post the unsetInterestFilter operation
- Not add the filter to the table
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.
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
- 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
- If
InterestFilter::undoAfterRegistration
is true call error callback
. Change on Face::Impl::asyncUnregisterPrefix
- If register do not exist set
InterestFilter::undoAfterRegistration
to true and call error callback
Also available in: Atom
PDF