Project

General

Profile

Actions

Feature #2991

closed

FaceManager: specify face persistency

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

Status:
Closed
Priority:
Normal
Assignee:
Category:
Management
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
3.00 h

Description

In faces/create command processing, allow creating a permanent face if the requester asks for FacePersistency::PERMANENT.

Necessary changes in ndn-cxx ControlParametersand FaceCreateCommandis included as part of this issue.


Related issues 4 (0 open4 closed)

Related to NFD - Feature #2993: nfdc: create permanent facesClosedJoao Pereira

Actions
Blocked by NFD - Feature #2990: FaceMgmt: specify face persistencyClosedJunxiao Shi

Actions
Blocked by NFD - Feature #2989: Minimal UDP permanent faceClosedYukai Tu

Actions
Blocks NFD - Feature #2994: UDP permanent face scenarioClosedHila Ben Abraham

Actions
Actions #1

Updated by Junxiao Shi over 9 years ago

  • Blocked by Feature #2990: FaceMgmt: specify face persistency added
Actions #2

Updated by Junxiao Shi over 9 years ago

Actions #4

Updated by Junxiao Shi over 9 years ago

This is a small change, and MAY be completed without waiting for #2107 completion.

Actions #5

Updated by Junxiao Shi over 9 years ago

Actions #6

Updated by Junxiao Shi over 9 years ago

Actions #7

Updated by Junxiao Shi over 9 years ago

  • Assignee set to Yukai Tu
Actions #8

Updated by Junxiao Shi over 9 years ago

  • Description updated (diff)
  • Estimated time changed from 2.00 h to 3.00 h

We need to reconsider note-4.

This issue needs to change ControlParameters which conflicts with the Dispatcher change in #2107.

Actions #9

Updated by Junxiao Shi over 9 years ago

20150821 conference call decides that this doesn't need to wait for Dispatcher. Yanbiao agrees to resolve conflicts in ControlParameters when they happen.

Actions #10

Updated by Yukai Tu over 9 years ago

  • Status changed from New to In Progress
  • Estimated time changed from 3.00 h to 1.00 h
Actions #11

Updated by Yukai Tu over 9 years ago

  • Estimated time changed from 1.00 h to 3.00 h
Actions #12

Updated by Alex Afanasyev over 9 years ago

@Yukai Can you finish updating the outstanding commits in gerrit by noon tomorrow? I don't like that we have dragged this issue up until the release (noon tomorrow) and I have to add disclaimer that even though we have support, but one cannot use it because management is missing for now... If you need help, I and other guys will be willing to help.

Actions #13

Updated by Junxiao Shi over 9 years ago

Reply to note-12:

Even if #2991 is done, it doesn't mean permface is ready for use. #2993 and #2994 are needed as well.

Release 0.3.4 is a snapshot release which includes whatever is available. The release is not a reason to rush any implementation.

Actions #14

Updated by Yukai Tu over 9 years ago

Can you give me some guides about unit tests under ndn-cxx? Thanks.

Actions #15

Updated by Yukai Tu over 9 years ago

I may need some helps when I doing unit test on ndn-cxx. Here are some error messages:

Running 607 test cases...

../tests/unit-tests/util/dns.t.cpp(59): fatal error in "Asynchronous": Resolved to 92.242.140.2, but should have failed

../tests/unit-tests/util/face-uri.t.cpp(87): error in "CanonizeUdpV4": udp4://invalid.invalid should fail

../tests/unit-tests/util/face-uri.t.cpp(88): error in "CanonizeUdpV4": check tc->m_expectedUri == canonicalUri.toString() failed [ != udp4://92.242.140.2:6363]

../tests/unit-tests/util/face-uri.t.cpp(87): error in "CanonizeTcpV4": tcp4://invalid.invalid should fail

../tests/unit-tests/util/face-uri.t.cpp(88): error in "CanonizeTcpV4": check tc->m_expectedUri == canonicalUri.toString() failed [ != tcp4://92.242.140.2:6363]

How can I fix these errors?

Actions #16

Updated by Junxiao Shi over 9 years ago

Answer to note-15:

You may be using a misbehaving/malicious DNS server.
If there is no other failure, you may ignore these errors.

Actions #17

Updated by Alex Afanasyev over 9 years ago

@Yukai Some ISPs provide "misbehaved" caching DNS resolvers that return bogus IP address of internal "search" engine, instead of failing to resolve the domain name. In my case, TimeWarner did that, so I configured my router's DHCP to use Google's DNS. I guess COX is also doing this.

You can either switch your DNS settings to use different caching resolver or, as Junxiao suggested, ignore these specific errors.

Actions #18

Updated by Junxiao Shi over 9 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF