Feature #3174
closedNACK counters
100%
Updated by Junxiao Shi about 9 years ago
- Blocks Task #3088: Refactor Face as LinkService+Transport added
Updated by Junxiao Shi about 9 years ago
- Assignee set to Eric Newberry
This shall solve NFD:commit:c2ee303880e6bfd79c107a4cda2cc28194356409 face-counters.hpp line328 problem.
Updated by Eric Newberry about 9 years ago
- Status changed from New to In Progress
Updated by Eric Newberry about 9 years ago
What TLV type values should I assign NInNacks and NOutNacks?
Updated by Junxiao Shi about 9 years ago
- Description updated (diff)
Answer to note-4: see updated spec with links to relevant wiki pages. TLV-TYPE codes are on the bottom of each page.
I notice that the TLV-TYPE codes I previously assigned in ForwarderStatus have conflicts in Face dataset. I have changed the codes to avoid this conflict.
Updated by Eric Newberry about 9 years ago
It appears that LinkCounters
also has NInPackets
and NOutPackets
counters, so ForwarderStatus
and FaceStatus
need those as well.
Updated by Junxiao Shi about 9 years ago
Updated by Eric Newberry about 9 years ago
- Status changed from In Progress to Code review
Updated by Junxiao Shi about 9 years ago
- Blocks deleted (Task #3088: Refactor Face as LinkService+Transport)
Updated by Junxiao Shi about 9 years ago
- Related to Feature #3177: LpFace counters added
Updated by Junxiao Shi about 9 years ago
Updated by Eric Newberry about 9 years ago
- Status changed from Code review to Closed
- % Done changed from 0 to 100
Updated by Alex Afanasyev about 9 years ago
- Status changed from Closed to Feedback
I have missed that originally, but my recent attempt to upgrade NFD version on android revealed that this is a breaking change for other libraries that implement ForwarderStatus and FaceStatus.
I would like to propose to make this change less intrusive: move all new fields to the end of the TLV. This way old libraries are not getting affected while parsing new status packet.
Updated by Junxiao Shi about 9 years ago
I disagree with note-13.
A correct implementation of a decoding procedure should check nothing extra exists at the end of a parent element, so any changes of a required element would be a breaking change, regardless of where it's placed.
The ordering "NInInterests, NInDatas, NInNacks, NOutInterests, NOutDatas, NOutNacks, NInPackets, NInBytes, NOutPackets, NOutBytes" follows the logical order of "incoming network later counters, outgoing network layer counters, incoming link layer counters, outgoing link layer counters".
The alternate would be a nonsense ordering.
Recommendation for NFD-Android:
- Do not upgrade NFD until the library is ready.
- If the library must support both versions of NFD Management protocol, it may implement the additional field as if it's an optional field.
Updated by Junxiao Shi about 9 years ago
- Status changed from Feedback to Closed
Closing because there's no more comment in past 60 days.