NFD

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.

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

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.

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.

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?

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.

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?

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;

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.

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

I can make the fix

http://gerrit.named-data.net/#/c/1445/

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.