NFD » ndn-cxx

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)

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.

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?

Junxiao Shi wrote in #note-6:

• The proper behavior is to throw an exception during Link::wireEncode, rather than encoding into an invalid packet.

This is infeasible in the current design because wireEncode is not virtual. As I said several times in other contexts, I believe deriving from Data was a mistake. Data is not designed to be subclassed.

Davide Pesavento wrote in #note-13:

deriving from Data was a mistake. Data is not designed to be subclassed.

I ran into similar problem when designing Certificate class in NDNts.
While it's easy to have virtual function in JavaScript (every function is in fact virtual), Certificate inheriting from Data has the drawback of constructing Data twice, and the caller can accidentally invalidate the Certificate structurally by assigning to Data fields.

The solution in NDNts is making data a field of Certificate.
In C++ syntax it looks like:

class Certificate
{
public:
  static Certificate fromData(Data data);

  Data getData() const;

  Name getName() const;

  Name getKeyName() const;

  ValidityPeriod getValidityPeriod() const;

  span<uint8_t> getPublicKeySpki() const;

private:
  Certificate(...);
};

Certificate class is immutable so that caller cannot invalidate it structurally by assignment.
Functions that create a Certificate, such as KeyChain::makeCertificate, constructs a Data first then calls Certificate::fromData.

There's no cert.isValid(now) function because the meaning of isValid() is ambiguous.
Instead, the call is cert.getValidityPeriod().includes(now).