NDN project issue tracking system: Issueshttps://redmine.named-data.net/https://redmine.named-data.net/favicon.ico?14759811232024-01-10T18:49:37ZNDN project issue tracking system
Redmine NLSR - Task #5308 (In Progress): Code cleanup in LSA and routing table related typeshttps://redmine.named-data.net/issues/53082024-01-10T18:49:37ZJunxiao ShiNFD - Feature #5277 (In Progress): Remove persistent faceshttps://redmine.named-data.net/issues/52772023-07-29T17:22:57ZJunxiao Shi
<p>As discussed in 20181119 NFD call, <em>persistent</em> semantics shall be removed from all face types, keeping only <em>on-demand</em> and <em>permanent</em> levels.</p>
PSync - Task #4911 (In Progress): IBLT::listEntries should initially clear the result setshttps://redmine.named-data.net/issues/49112019-04-11T12:44:38ZAnonymous
<p>IBLT::listEntries takes a reference to the positive and negative sets and inserts values:<br>
<a href="https://github.com/named-data/PSync/blob/0cf4b600e91455ee07c38eb22876aa6b653bc14b/PSync/detail/iblt.cpp#L148">https://github.com/named-data/PSync/blob/0cf4b600e91455ee07c38eb22876aa6b653bc14b/PSync/detail/iblt.cpp#L148</a></p>
<p>Normally, listEntries is called with new empty sets. But if the sets are re-used in a future call to listEntries, there could be unexpected side effects. </p>
<p>For example, the following unit test re-uses these sets. Luckily this test still works, even though there could have been unexpected side effects of re-using the sets:<br>
<a href="https://github.com/named-data/PSync/blob/0cf4b600e91455ee07c38eb22876aa6b653bc14b/tests/test-iblt.cpp#L150">https://github.com/named-data/PSync/blob/0cf4b600e91455ee07c38eb22876aa6b653bc14b/tests/test-iblt.cpp#L150</a></p>
<p><a href="https://github.com/named-data/PSync/blob/0cf4b600e91455ee07c38eb22876aa6b653bc14b/tests/test-iblt.cpp#L159">https://github.com/named-data/PSync/blob/0cf4b600e91455ee07c38eb22876aa6b653bc14b/tests/test-iblt.cpp#L159</a></p>
<p>I suggest that listEntries should first clear the entries, and explain this in the method documentation.</p>
<pre><code>positive.clear();
negative.clear();
</code></pre>
<p>This is a low-priority comment because IBLT is only used in the PSync code which always calls listEntries with new empty sets. But it is a small change and could avoid future confusion.</p>
PSync - Bug #4818 (Code review): murmurHash3 of uint32_t is not endian safehttps://redmine.named-data.net/issues/48182019-01-28T06:44:56ZAnonymous
<p>murmurHash3 of an uint32_t value computes the hash of the in-memory 4-byte buffer. If this is part of a data structure that is sent to another computer with a difference between big endian and little endian, then they won't compute the same hash.<br>
<a href="https://github.com/named-data/PSync/blob/0cf4b600e91455ee07c38eb22876aa6b653bc14b/PSync/detail/util.cpp#L103">https://github.com/named-data/PSync/blob/0cf4b600e91455ee07c38eb22876aa6b653bc14b/PSync/detail/util.cpp#L103</a></p>
<p>Maybe this should use endian::native_to_little, similar to the TLV encoder (Intel chips use little endian):<br>
<a href="https://github.com/named-data/ndn-cxx/blob/master/ndn-cxx/encoding/encoder.cpp#L151">https://github.com/named-data/ndn-cxx/blob/master/ndn-cxx/encoding/encoder.cpp#L151</a></p>
PSync - Task #4659 (Code review): Look into using newer and better hash functionhttps://redmine.named-data.net/issues/46592018-07-09T15:03:53ZAshlesh Gawande
<p>Currently we use Murmurhash3, but newer and faster hashes are available:<br>
CityHash (NFD uses it), FarmHash, xxHash (<a href="http://cyan4973.github.io/xxHash/">http://cyan4973.github.io/xxHash/</a>)</p>