Project

General

Profile

Actions
Copy link

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.

Status:
Closed
Priority:
Normal
Assignee:
Junxiao Shi
Category:
Utils
Target version:
v0.3
Start date:
Due date:
% Done:

100%

Estimated time:
2.00 h

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.

Related issues 1 (0 open — 1 closed)

Blocks NFD - Feature #1999: Strategy for access routerClosedJunxiao Shi

Actions
Actions
Copy link
 #1

Updated by Junxiao Shi over 9 years ago

Actions
Copy link
 #2

Updated by Alex Afanasyev over 9 years ago

  • 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.

Actions
Copy link
 #3

Updated by Junxiao Shi over 9 years ago

  • 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.

Actions
Copy link
 #4

Updated by Junxiao Shi over 9 years ago

  • Status changed from New to In Progress
  • Assignee set to Junxiao Shi
  • Estimated time set to 2.00 h
Actions
Copy link
 #5

Updated by Junxiao Shi over 9 years ago

  • % Done changed from 0 to 20

Some investigation reveals that:

  • Face won't connect to Transport until sending the first packet
  • DummyClientFace::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
Actions
Copy link
 #6

Updated by Junxiao Shi over 9 years ago

  • Status changed from In Progress to Code review
  • % Done changed from 20 to 100
Actions
Copy link
 #7

Updated by Junxiao Shi over 9 years ago

  • 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.

Actions
Copy link
 #8

Updated by Junxiao Shi over 9 years ago

  • Status changed from In Progress to Code review
  • % Done changed from 50 to 100

http://gerrit.named-data.net/1574 patchset 3 implements note-7 idea.

Actions
Copy link
 #9

Updated by Junxiao Shi over 9 years ago

  • Status changed from Code review to Closed
Actions
Copy link

Also available in: Atom PDF