Feature #3731
closed
FaceManager commands: LocalFieldsEnabled
Added by Junxiao Shi over 8 years ago. Updated almost 8 years ago.
100%
Description
In faces/create and faces/update commands, accept Flags+Mask fields, and process LocalFieldsEnabled attribute.
This issue includes necessary updates to ControlParameters struct and ndn::nfd::FaceUpdateCommand class.
faces/enable-local-control and faces/disable-local-control command should be kept for backwards compatibility.
This issue does not change any client side application still using the old command.
Updated by Junxiao Shi over 8 years ago
- Subject changed from FaceManager: LocalFieldsEnabled to FaceManager commands: LocalFieldsEnabled
- Start date deleted (
08/11/2016)
Updated by Junxiao Shi over 8 years ago
- Blocked by Task #3226: Redesign faces/enable-local-control added
Updated by Junxiao Shi over 8 years ago
- Blocks Task #3734: RibManager: enable local fields with faces/update command added
Updated by Eric Newberry over 8 years ago
- Status changed from New to In Progress
Updated by Junxiao Shi over 8 years ago
- Blocked by Bug #3232: Inaccurate log message when changing FacePersistency added
Updated by Junxiao Shi over 8 years ago
Updated by Eric Newberry over 8 years ago
- % Done changed from 0 to 40
I uploaded the ndn-cxx portion of this task to Gerrit.
Updated by Junxiao Shi over 8 years ago
- Blocked by deleted (Bug #3232: Inaccurate log message when changing FacePersistency)
Updated by Junxiao Shi over 8 years ago
- Blocks Bug #3232: Inaccurate log message when changing FacePersistency added
Updated by Junxiao Shi over 8 years ago
NFD portion of this issue can start now.
faces/update command should be introduced in this issue, but it only supports Flags+Mask of LocalFieldsEnabled bit; if FacePersistency is specified in a faces/update command, the update is invalid and 409 should be returned with FacePersistency field in the <body>.
Updated by Eric Newberry over 8 years ago
I just noticed a mistake I made in the ndn-cxx portion of this task that made it through code review.
The current implementation of FaceUpdateCommand::applyDefaultsToRequest causes a FaceId of 0 be set in all faces/update requests, even if FaceId is already set. The proper behavior is to set FaceId to 0 only if the parameter is not set.
I will be push a fix to Gerrit momentarily.
Updated by Junxiao Shi over 8 years ago
I'm trying to use IncomingFaceId for FaceMgmt self-updating. The NDNLPv2 spec states that IncomingFaceId should be attached by NFD to every packet going to a local application (how about Management?). However, it does not appear to me that this is the current behavior. Am I interpreting the LP spec (from the Redmine wiki) correctly or do I need to rely on another feature for self-updating?
IncomingFaceId tag is available only if management’s face has LocalFieldsEnabled=yes.
Since management cannot send a faces/update command to itself, it should directly update the relevant property on GenericLinkService of its own face.
Then, see an example in FibManager on how to access the tag.
Updated by Eric Newberry over 8 years ago
- Status changed from In Progress to Code review
- % Done changed from 40 to 100
I believe that I've completed the code and test cases for NFD. I'm waiting for the ndn-cxx fix at Gerrit 3901 to be committed before pushing my changes to NFD.
Updated by Eric Newberry over 8 years ago
I've pushed what I have for NFD to Gerrit. I haven't completely finished verifying and reviewing the functionality, so I've marked it as a work-in-progress.
Updated by Eric Newberry about 8 years ago
In light of the discussion on Gerrit between Alex, Davide, and I, I would like to propose some changes to the design of faces/create:
The create command (FaceManager::createFace) will verify the parameters that apply to all factories, like the inability to create multicast faces. After this, it will parse the URI and determine the applicable factory (if any). Then, it will call a function in the factory (Factory::canCreateFromFaceManager) that will return whether the face can be created from the face manager. If not, the command will fail with 406 ("Unsupported protocol"). Otherwise, createFace will call Factory::createFaceFromManager. This function will serve as a wrapper around Factory::createFace and will perform factory-specific checks, like those for FacePersistency, and will return a status code and message through the manager.
Updated by Junxiao Shi about 8 years ago
The original design intention is: FaceManager is only responsible for finding the correct ProtocolFactory subclass; ALL checks, including multicast address and persistency, should be performed within ProtocolFactory (and it can be further delegated to Channel etc).
Updated by Junxiao Shi about 8 years ago
- Blocks Task #1942: NextHopFaceId test scenario added
Updated by Eric Newberry about 8 years ago
@Junxiao I think this task is complete. Is there anything else that still needs to be done?
Updated by Junxiao Shi about 8 years ago
- Status changed from Code review to Closed
Updated by Davide Pesavento almost 8 years ago
We forgot to update the NFD dev guide, which still contains many references to LocalControlHeader & co.
Updated by Junxiao Shi almost 8 years ago
NFD devguide shall be updated after #3232 is complete, so that description about faces/update command can cover both features.