Project

General

Profile

Actions

Bug #4838

closed

Possible issues hashing the name URI, not the TLV

Added by Anonymous about 5 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Low
Assignee:
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:

Description

This is a low priority observation. When ProducerBase::updateSeqNo computes the new hash, it uses the name URI string.
https://github.com/named-data/PSync/blob/0cf4b600e91455ee07c38eb22876aa6b653bc14b/PSync/producer-base.cpp#L121

uint32_t newHash = murmurHash3(N_HASHCHECK, prefixWithSeq.toUri());

I don't think that the NDN packet spec guarantees that all implementations will create the same URI string for a Name. For example upper/lower case for hex digits, different ways of representing the name component type number, different choices of which values to percent escape, etc. Also, because of lots of conversion from binary to decimal/hexadecimal values and string concatenation, it can be less efficient to get the URI string than to encode the name TLV. (Of course, if consumers and producers have different implementations of toUri(), their hashes will not match.)

For these reasons, I humbly suggest that PSync should compute the hash from the Name TLV encoding, not from the URI string.

Actions #1

Updated by Anonymous about 5 years ago

  • Description updated (diff)
Actions #2

Updated by Anonymous about 5 years ago

  • Description updated (diff)
Actions #4

Updated by Davide Pesavento over 2 years ago

  • Tracker changed from Task to Bug
  • Status changed from New to Code review
  • Target version set to v0.4.0
  • Start date deleted (02/06/2019)
Actions #5

Updated by Junxiao Shi about 2 years ago

Please set assigned to me and close this issue.

Actions #6

Updated by Davide Pesavento about 2 years ago

  • Status changed from Code review to Closed
  • Assignee set to Junxiao Shi
  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF