Project

General

Profile

Bug #3803

ndn::Link is encoded as ContentType==BLOB if no delegation is added

Added by Muhammad Hosain Abdullahi Sabet over 3 years ago. Updated over 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Base
Target version:
-
Start date:
10/10/2016
Due date:
% Done:

0%

Estimated time:

Description

Snippet to reproduce:

// g++ -std=c++11 -o x x.cpp $(pkg-config --cflags --libs libndn-cxx)
#include <ndn-cxx/link.hpp>
#include <ndn-cxx/security/key-chain.hpp>

int main()
{
  auto link = std::make_shared<ndn::Link>("/link-name");
  ndn::KeyChain keyChain;
  keyChain.sign(*link);
  std::cout << *link;
  return 0;
}

Expected: ContentType==LINK, or an exception is thrown
Actual: ContentType==BLOB

History

#1

Updated by Junxiao Shi over 3 years ago

  • Description updated (diff)

I can't fully understand the problem. Can you post a code snippet the reproduce the problem? If it isn't posted within next 7 days, this issue will be rejected.

#2

Updated by Muhammad Hosain Abdullahi Sabet over 3 years ago

This is a sample ndnSIM code snippet:

  ndn::Name linkName = m_prefix;
  auto linkObject = make_shared < ::ndn::Link>(linkName.append(ndn::Name("/Link")));
  ndn::Signature sign;
  ndn::SignatureInfo signInfo(static_cast< ::ndn::tlv::SignatureTypeValue>(255));
  sign.setInfo(signInfo);
  //linkObject->addDelegation(1,Name("/google"));
  //linkObject->addDelegation(2,Name("/Verizon"));
  sign.setValue(::ndn::nonNegativeIntegerBlock(::ndn::tlv::SignatureValue, 0));
  linkObject->setSignature(sign);

  m_appLink->onReceiveData(*linkObject);
  NS_LOG_DEBUG("This data has been sent"<<*linkObject);

Having above, below will be printed:

This data has been sentName: /LinkHolder/Link
MetaInfo: ContentType: 0
Content: (size: 0)
Signature: (type: 255, value_length: 1)

#3

Updated by Junxiao Shi over 3 years ago

  • Subject changed from LINKs without DelegationName considered as ContentType_Blob to ndn::Link is encoded as ContentType==BLOB if no delegation is added
  • Description updated (diff)
  • Category set to Base
  • Target version set to v0.6

While I can confirm the problem with a snippet that does not involve ndnSIM, I'm unsure whether this is indeed a bug, because the semantics of a Link without delegation is unclear.
We may as well consider a Link without delegation as invalid. But in that case, Link::wireEncode should throw an exception instead of encoding as BLOB.

#4

Updated by Muhammad Hosain Abdullahi Sabet over 3 years ago

Junxiao Shi wrote:

While I can confirm the problem with a snippet that does not involve ndnSIM, I'm unsure whether this is indeed a bug, because the semantics of a Link without delegation is unclear.

I've been thinking on whether or not this is a bug, from the beginning. I think this is a bug in a sense that having this packet with ContentType=0, currently nothing indicates what the problem is, which is a Link object not having delegation name. So nether consumer nor producer can find the problem unless, like in my case, one already knows.

#5

Updated by Muhammad Hosain Abdullahi Sabet over 3 years ago

Junxiao Shi wrote:

We may as well consider a Link without delegation as invalid. But in that case, Link::wireEncode should throw an exception instead of encoding as BLOB.

Currently there is no Link::wireEncode. We use Data::wireEncode and Link::encodeContent for encoding. I can add the function to ::ndn::Link temporarily, but isn't it better to clarify the semantics of a Link object without delegationName?
Since new version of ndnSIM is not released yet, could we add this functioanilty into the associated version of ndn-cxx?

#6

Updated by Junxiao Shi over 3 years ago

  • Description updated (diff)
  • Target version deleted (v0.6)

20161020 call decides that:

  • Link without delegation is invalid, according to #2587 link.pdf definition.
  • The proper behavior is to throw an exception during Link::wireEncode, rather than encoding into an invalid packet.
  • Since this situation is purely hypothetical, there's no urgent need to fix this bug.
  • Alex is willing to accept the proposed patch as long as it does not require major refactoring.
#7

Updated by Muhammad Hosain Abdullahi Sabet about 3 years ago

  • Status changed from New to In Progress
#8

Updated by Junxiao Shi over 2 years ago

  • Description updated (diff)
  • Status changed from In Progress to New

Also available in: Atom PDF