Project

General

Profile

Actions

Bug #3693

closed

integ fails due to improper Exclude usage

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

Status:
Closed
Priority:
Normal
Assignee:
Category:
Integration Tests
Target version:
Start date:
08/01/2016
Due date:
% Done:

100%

Estimated time:
1.00 h

Description

IntegrationTests FIB matching scenario is failing because of improper Exclude usage.

Step 22 sends an Interest ndn:/D Exclude=[,D].
The Interest is sent to a traffic generator server which responds a Data with name ndn:/D/<implicit-digest>.
However, Exclude=[,D] implies any implicit digest component, as well as generic name component up to "D" are excluded, so this Data will not match the Interest.
This breaks the expectation of the consumer side that a Data will be received.

To solve this problem, the Interest should be changed to ndn:/D Exclude=[...,D] where ... denotes a zero-length generic name component.

Step 24 has the same problem.


Files

20160804101410.tgz (177 KB) 20160804101410.tgz integ 3016,3 Junxiao Shi, 08/04/2016 07:34 AM

Related issues 1 (0 open1 closed)

Related to ndn-cxx - Bug #3665: Exclude doesn't support ranged operations using ImplicitSha256DigestComponentClosedJunxiao Shi

Actions
Actions #1

Updated by Junxiao Shi over 8 years ago

Also, FIB matching scenario design contains "Do prefix registration using NFD FibMgmt" which is no longer necessary since NFD-RIB is readily available. This clause should be deleted.

Actions #2

Updated by Junxiao Shi over 8 years ago

  • Subject changed from integ fails due to improper Exclude to integ fails due to improper Exclude usage
  • Description updated (diff)
Actions #3

Updated by Junxiao Shi over 8 years ago

  • Related to Bug #3665: Exclude doesn't support ranged operations using ImplicitSha256DigestComponent added
Actions #4

Updated by Eric Newberry over 8 years ago

  • Assignee set to Eric Newberry
Actions #5

Updated by Eric Newberry over 8 years ago

  • Status changed from New to In Progress
Actions #6

Updated by Eric Newberry over 8 years ago

Does [...,D] indicate that ExcludeBefore should include both components ("..." and "D") or that ExcludeAfter should be "..." and ExcludeBefore should be "D"?

Actions #7

Updated by Junxiao Shi over 8 years ago

Answer to note-6:

[...,D] is using mathematical notation. It's encoded as <NameComponent/><Any/><NameComponent>D</NameComponent> and can be created from Exclude().excludeRange(name::Component(), name::Component("D")).

Actions #8

Updated by Eric Newberry over 8 years ago

  • % Done changed from 0 to 90

In order to allow empty Excludes in ndn-traffic-generator, I believe I need to make changes to the client. I've tried adding the ExcludeBeforeEmpty=[0-1] and ExcludeAfterEmpty=[0-1] options and this appears to make the test run successfully. I will submit the ndn-traffic-generator patch to gerrit referencing this issue.

Actions #9

Updated by Eric Newberry over 8 years ago

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

Updated by Junxiao Shi over 8 years ago

Reply to note-8:

The semantics of ExcludeBeforeEmpty and ExcludeAfterEmpty are unclear, because there's no corresponding structure in either packet format or ndn::Exclude class.
It's better to use a structure that matches packet format or ndn::Exclude class, such as:

ExcludeRange=comp0,comp1

where comp0 and comp1 are two name components in URI representation.

This is converted into a function call exclude.excludeRange(name::Component::fromEscapedString(comp0), name::Component::fromEscapedString(comp1)).

Actions #11

Updated by Junxiao Shi over 8 years ago

Actions

Also available in: Atom PDF