Project

General

Profile

Task #1993

Face query operation

Added by Junxiao Shi about 5 years ago. Updated almost 5 years ago.

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

100%

Estimated time:
7.00 h

Description

Implement Query Operation in FaceManager.

This Task includes:

  • evaluate query conditions on a face
    • Conditions can be evaluated on nfd::Face directly, using its properties
    • Alternatively, FaceStatus can be requested from every face, and conditions can be evaluated on FaceStatus block
    • The design choice shall be justified
  • in FaceManager, accept query Interest and publish result dataset

Related issues

Blocked by NFD - Task #1992: Replace FaceFlags with individual fieldsClosed

Blocks NFD - Task #1995: nfdc: accept FaceUri in all commandsClosed

Blocked by ndn-cxx - Task #2085: add FaceQueryFilter typeClosed

Blocked by NFD - Task #1722: FaceMgmt: query operationClosed

Blocked by ndn-cxx - Task #2128: Deduplicate tlv::ContentTypeValue and MetaInfo::TYPE_*Closed

History

#1 Updated by Junxiao Shi about 5 years ago

  • Blocked by Task #1992: Replace FaceFlags with individual fields added

#2 Updated by Junxiao Shi about 5 years ago

  • Description updated (diff)
  • Estimated time changed from 5.00 h to 8.00 h

#3 Updated by Junxiao Shi almost 5 years ago

  • Blocks Task #1995: nfdc: accept FaceUri in all commands added

#4 Updated by Chengyu Fan almost 5 years ago

  • Assignee set to Chengyu Fan

#5 Updated by Chengyu Fan almost 5 years ago

Here is the design for this task. Please point it out if I understand sth incorrectly.

  1. in ndn-cxx, add FaceQueryFilter type, use FaceTraits as the base class.

  2. To evaluate the query conditions, there should be a class QueriedFaceStatusPublisher, which inherits the class FaceStatusPublisher, and overrides the generate() functions. The QueriedFaceStatusPublisher should generate FaceQueryFilter data by comparing with the filter contained in the Interest.

  3. in FaceManager, accept the query Interests and process it using a new unsignedVerbProcessor.

#6 Updated by Junxiao Shi almost 5 years ago

@Steve, please review/approve the design in note-5.

#7 Updated by Anonymous almost 5 years ago

Chengyu Fan wrote:
Here is the design for this task. Please point it out if I understand sth incorrectly.

  1. in ndn-cxx, add FaceQueryFilter type, use FaceTraits as the base class.

I'm not familiar with these classes, so I'm going to assume this is correct. Traditionally, tasks that involve adding to or modifying ndn-cxx have a corresponding task in the ndn-cxx project.

  1. To evaluate the query conditions, there should be a class QueriedFaceStatusPublisher, which inherits the class FaceStatusPublisher, and overrides the generate() functions. The QueriedFaceStatusPublisher should generate FaceQueryFilter data by comparing with the filter contained in the Interest.

This is mostly right, but I don't think there's a compelling reason to inherit from FaceStatusPublisher (correct me if I'm wrong). I think you should inherit from its parent, SegmentPublisher (under core) instead.

Also, I would just call the new class FaceQueryPublisher.

  1. in FaceManager, accept the query Interests and process it using a new unsignedVerbProcessor.

Yes.

#8 Updated by Chengyu Fan almost 5 years ago

Steve DiBenedetto wrote:

Chengyu Fan wrote:
Here is the design for this task. Please point it out if I understand sth incorrectly.

  1. in ndn-cxx, add FaceQueryFilter type, use FaceTraits as the base class.

I'm not familiar with these classes, so I'm going to assume this is correct. Traditionally, tasks that involve adding to or modifying ndn-cxx have a corresponding task in the ndn-cxx project.

I'll create another ndn-cxx task for adding FaceQueryFilter type.

  1. To evaluate the query conditions, there should be a class QueriedFaceStatusPublisher, which inherits the class FaceStatusPublisher, and overrides the generate() functions. The QueriedFaceStatusPublisher should generate FaceQueryFilter data by comparing with the filter contained in the Interest.

This is mostly right, but I don't think there's a compelling reason to inherit from FaceStatusPublisher (correct me if I'm wrong). I think you should inherit from its parent, SegmentPublisher (under core) instead.

Also, I would just call the new class FaceQueryPublisher.

I think you are right, I will use this design.

  1. in FaceManager, accept the query Interests and process it using a new unsignedVerbProcessor.

Yes.

#9 Updated by Junxiao Shi almost 5 years ago

  • Blocked by Task #2085: add FaceQueryFilter type added

#10 Updated by Junxiao Shi almost 5 years ago

  • Description updated (diff)
  • Estimated time changed from 8.00 h to 7.00 h

I meant to include ndn-cxx's FaceQueryFilter type as part of this Task, but #2085 is created, so I'm deleting that item from this Task.

#11 Updated by Chengyu Fan almost 5 years ago

  • Status changed from New to In Progress

#12 Updated by Chengyu Fan almost 5 years ago

  • % Done changed from 0 to 30

#13 Updated by Chengyu Fan almost 5 years ago

For the current design of Face Dataset, there is no field called UriScheme, but it is required in the FaceQueryFilter type.

So how to handle the filter that contains this field?

#14 Updated by Alex Afanasyev almost 5 years ago

I would just directly use UriScheme parameter in the query to request FaceDataset only from faces that match the scheme. It is kind of wasteful to request everything and then do filtering.

#15 Updated by Chengyu Fan almost 5 years ago

I agree.

But the Face class does not contain such attribute UriScheme, what I'm confused is how to handle a filter with the UriScheme parameter? Do I need to modify the Face class to support UriScheme?

#16 Updated by Junxiao Shi almost 5 years ago

This Task MUST NOT modify Face dataset.

The UriScheme condition is evaluated on RemoteUri and LocalUri attributes of FaceStatus element:

UriScheme permits a face if the scheme part of its local FaceUri or remote FaceUri equals the value

bool matchesUriScheme = filter.uriScheme == faceStatus.localUri.scheme ||
                        filter.uriScheme == faceStatus.remoteUri.scheme;

#17 Updated by Chengyu Fan almost 5 years ago

  • % Done changed from 30 to 70

#18 Updated by Chengyu Fan almost 5 years ago

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

#19 Updated by Junxiao Shi almost 5 years ago

  • Blocked by Task #1722: FaceMgmt: query operation added

#20 Updated by Junxiao Shi almost 5 years ago

Producer generated NACK is available in ndn-cxx as of commit cad32e3a84c28a035e721828f24a07b88692f690.
If the assignee wants, an invalid query filter could be responded to with a producer generated NACK.

I won't define this in the protocol, because management protocol is not supposed to use a non-standardized feature.
The behavior of invalid query filter would be left undefined in the protocol.

#21 Updated by Junxiao Shi almost 5 years ago

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

First commit is merged. Another commit is needed to add producer-generated NACK in response to an invalid FaceQueryFilter.

#22 Updated by Junxiao Shi almost 5 years ago

  • Blocked by Task #2128: Deduplicate tlv::ContentTypeValue and MetaInfo::TYPE_* added

#23 Updated by Junxiao Shi almost 5 years ago

tests/daemon/mgmt/face-query-status-publisher-common.hpp in commit 320d23334f01cf481bb2ce9d1f66afbbf967aa51 is causing build errors. Please fix immediately.

#24 Updated by Alex Afanasyev almost 5 years ago

I can make the fix

#26 Updated by Chengyu Fan almost 5 years ago

Thanks, @Alex.

I just received the message. You're right that the message is from the misuse of the content type.

I will continue this task using the new content type.

#27 Updated by Chengyu Fan almost 5 years ago

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

#28 Updated by Junxiao Shi almost 5 years ago

  • Status changed from Code review to Closed

Also available in: Atom PDF