NFD » ndn-cxx

What does "fixed-width unsigned integer" mean anyway? Does the spec say how it should be encoded (its endianness for instance)?

And why don't we change the protocol spec instead of the code? It doesn't seem that Sequence has uses where it may need to be changed in place (thus potentially changing the encoding length), so nonNegativeInteger shouldn't be slower in any noticeable way.

nonNegativeInteger shouldn't be slower in any noticeable way.

It is slower because decoder contains branching instructions. The decoder is still readNonNegativeInteger for now, but I plan to change it to read uint64 after a release.

I bet the difference is not even measurable. And even in the fixed-width case, you still need at least one branch to check that the size is what you expect.

Having less branching (one) is always faster than having more branching (four). It will be measurable when executed millions of times.

Only one branch is ever taken. The difference is in the number of comparisons.

Regardless, we're not having this argument. It would apply to many other things that are in the protocol, some much worse than nonNegativeInteger.

20180418 NFD call decides that this Change can proceed.

just to double check, the spec doesn't mandate a specific endianness, that's also a per-link decision I guess

I see no reason to mandate a specific endianness. ndn-cxx uses big endian to be compatible with prior versions, but other links can choose differently.

NFD's LpReliability assumes Ack is NNI. This is updated in https://gerrit.named-data.net/4693.
Test case for LpReliability is somewhat simplified because Ack numbers don't make a difference in piggybacking calculation.

I’m thinking about a better idea on calculating the size of a piggybacked field:

size_t sizeofAck = lp::Packet::estimateSize<lp::AckField>(ack);

This can avoid the errorprone field size calculation in NFD’s LinkService.

However, I’d rather do this under a different issue.

will be changed to fixed-width after the upcoming release.

That shall be a separate issue. #4598