Project

General

Profile

Bug #1771

Incorrect logic in pit::Entry::canForwardTo

Added by Alex Afanasyev over 7 years ago. Updated about 7 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Forwarding
Target version:
Start date:
07/17/2014
Due date:
% Done:

0%

Estimated time:

Description

Part of the decision whether an Interest can be forwarded to face is related to incoming entries:

InRecordCollection::const_iterator inIt = std::find_if(
  m_inRecords.begin(), m_inRecords.end(),
  bind(&predicate_FaceRecord_ne_Face_and_unexpired, _1, &face, time::steady_clock::now()));
bool hasUnexpiredOtherInRecord = inIt != m_inRecords.end();
if (!hasUnexpiredOtherInRecord) {
  return false;
}

This code essentially prohibits Interests to be forwarded to any face from which Interest for the same name was recently received. While this effectively prevents Interests to be forwarded to the same face the Interest were received from, this logic is incorrect as it prevents other use cases. In particular, some ChronoSync operations would be harmed by this. Consider the following example

   +------+  /sync                +------+
   |      | >>>                   |      |
   |      | --------------------- |      |
   +------+                  <<<< +------+
      ^                     /sync     ^
      | ^                             | ^
      | ^                             | ^
      |                               |
     App                             App

Application sends /sync interest, which is propagated to the other node. The other node sends the same Interests, which should be propagated down to the application. The logic above prevent this to happen.


Related issues

Related to NFD - Feature #1756: Let strategy pick outgoing Interest packetClosedJunxiao Shi

Actions
#1

Updated by Junxiao Shi over 7 years ago

The design is: An Interest cannot be forwarded to a sole downstream.

If A and B both express an Interest, neither is sole downstream.
A's Interest (with A's Nonce) can be forwarded to B.

Are you saying the design is wrong, or the implementation doesn't match the design?

#2

Updated by Alex Afanasyev over 7 years ago

Ehmm.. Ok. My original thinking was not correct, but I still don't really understand what this check is doing and what is this "sole downstream".

The only check that should be (here or in strategy) is that the Interest should not be forwarded to the face from where it was received. Why do we need such a complicated check which is not easy to understand?

#3

Updated by Alex Afanasyev over 7 years ago

  • Target version changed from v0.2 to v0.3
#4

Updated by Junxiao Shi over 7 years ago

  • Related to Feature #1756: Let strategy pick outgoing Interest packet added
#5

Updated by Junxiao Shi about 7 years ago

  • Status changed from New to Rejected

See explanation in note-1.

Also available in: Atom PDF