Bug #2318
closed
DummyClientFace: setInterestFilter(InterestFilter, OnInterest) is not effective by itself
Added by Junxiao Shi over 9 years ago.
Updated over 9 years ago.
Description
Snippet to reproduce:
#include <ndn-cxx/util/dummy-client-face.hpp>
#include <boost/asio.hpp>
using std::bind;
using std::shared_ptr;
using ndn::Name;
using ndn::Interest;
using ndn::util::DummyClientFace;
int
main()
{
boost::asio::io_service io;
shared_ptr<DummyClientFace> face = ndn::util::makeDummyClientFace(io, {false, true});
//face->setInterestFilter(Name("/"), bind([]{}), bind([]{}));
face->setInterestFilter(Name("/"),
bind([] (const Interest& interest) { std::cout << interest << std::endl; }, _2));
io.poll();
io.reset();
Interest interest("/A");
face->receive(interest);
io.poll();
io.reset();
return 0;
}
Expected: Interest is received by handler.
Actual: Interest is not received by handler.
Note: If the registerPrefix+setInterestFilter combination operation is uncommented, the handler can receive the Interest.
- Start date deleted (
12/22/2014)
I don't get how this can block anything. What you described as a bug is actually a legitimate behavior of Face class.
This can be considered as improvement of DummyFace, but I'm rejecting the fact that it blocks anything.
- Subject changed from DummyClientFace: setInterestFilter(Name, OnInterest) is not effective by itself to DummyClientFace: setInterestFilter(InterestFilter, OnInterest) is not effective by itself
Face::setInterestFilter(InterestFilter, OnInterest) API shouldn't rely on a prefix registration made from the same Face.
Any Interest delivered by Transport that matches the InterestFilter should invoke OnInterest handler, regardless of whether a prefix registration exists.
This blocks #1999 because a test case needs to use this API.
- Status changed from New to In Progress
- Assignee set to Junxiao Shi
- Estimated time set to 2.00 h
- % Done changed from 0 to 20
Some investigation reveals that:
Face won't connect to Transport until sending the first packetDummyClientFace::receive requires the Face to be connected to Transport before a packet can be delivered
My solution is:
- add
Face::forceConnect method which causes Face to connect to Transport
- invoke
Face::forceConnect in makeDummyClientFace
- Status changed from In Progress to Code review
- % Done changed from 20 to 100
- Status changed from Code review to In Progress
- % Done changed from 100 to 50
I would suggest a different change. Instead of face being connected only on demand, we can only "resume" it on demand. In other words, we can always connect in the constructor (start async connection in the constructor). There is no harm done. When Interest is sent or prefix is registered, the transport needs to be resumed.
Agreed.
- Status changed from In Progress to Code review
- % Done changed from 50 to 100
- Status changed from Code review to Closed
Also available in: Atom
PDF
Updated by 
Updated by