Project

General

Profile

Feature #2879

NDNLPv2: Packet and Fields

Added by Junxiao Shi over 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Base
Target version:
Start date:
06/10/2015
Due date:
% Done:

100%

Estimated time:
9.00 h

Description

Implement NDNLPv2 functionality.

This issue includes these parts of #2841 API:

  • Field concept check
  • SequenceField FragIndexField FragCountField NackField NextHopFaceIdField CachingPolicyField IncomingFaceIdField typedefs
  • templates and specializations to support above typedefs
  • Packet class field accessors and encoding/decoding procedures

Related issues

Blocked by ndn-cxx - Feature #2875: NDNLPv2: TLV-TYPE codesClosed

Blocked by ndn-cxx - Feature #2876: NDNLPv2: simple value type declarationClosed

Blocked by ndn-cxx - Feature #2878: NDNLPv2: Nack abstractionClosed

Blocked by ndn-cxx - Feature #2998: Block::insert and Block::eraseClosed2015-07-07

Blocks ndn-cxx - Feature #2930: Face: send and receive NACKClosed

Blocked by ndn-cxx - Bug #3070: Block::remove unexpected semanticsClosed2015-07-26

History

#1 Updated by Junxiao Shi over 4 years ago

This is an "oversized" issue, estimated to be 9 hours.

I find it unreasonable to split into "field declarations" and "Packet class", because what goes into field declarations would affect how methods in Packet class are implemented.

#2 Updated by Junxiao Shi over 4 years ago

#3 Updated by Junxiao Shi over 4 years ago

  • Blocked by Feature #2876: NDNLPv2: simple value type declaration added

#4 Updated by Junxiao Shi over 4 years ago

#5 Updated by Eric Newberry over 4 years ago

  • Status changed from New to In Progress

#6 Updated by Junxiao Shi about 4 years ago

#7 Updated by Eric Newberry about 4 years ago

What in #2998 blocks this feature?

#8 Updated by Junxiao Shi about 4 years ago

Reply to note-7:

Protocol requires header fields in LpPacket to appear in the order of increasing TLV-TYPE codes.

Suppose LpPacket already has header 82 and header 85, and now header 84 is being added.

It's inconvenient to maintain the order with Block::push_back and Block::erase alone; Block::insert would allow inserting header 84 before header 85.

#9 Updated by Junxiao Shi about 4 years ago

#10 Updated by Junxiao Shi about 4 years ago

#2998 is mostly complete but not yet merged. This issue can proceed as follows:

  1. Create a local branch dev2879.
  2. Locally replace encoding/block.* with files in latest commit of #2998.
  3. Start development, commit locally when appropriate.
  4. If you want to submit to Gerrit, mark -2 to prevent accidental merge.

When #2998 is merged:

  1. Merge master branch into feature-ndnlp branch. This has to be a separate commit with minimal changes in other files.
  2. Wait for the merge commit to get merged into feature-ndnlp branch.
  3. In dev2879 branch, revert changes to encoding/block.*.
  4. Rebase dev2879 onto feature-ndnlp.
  5. Continue development.
  6. Upload to Gerrit as usual. If you've previously posted -2, unset it.

#11 Updated by Eric Newberry about 4 years ago

Junxiao Shi wrote:

  1. Locally replace encoding/block.* with files in latest commit of #2998.

There is a problem with doing this: The version of block.cpp/hpp in #2998 uses functions in other files that were merged after feature-ndnlp was split off from master. This causes the compile to fail.

#12 Updated by Junxiao Shi about 4 years ago

#2998 is merged now. This issue should proceed as follows:

  1. Merge master branch into feature-ndnlp branch. This has to be a separate commit with minimal changes in other files.
  2. Wait for the merge commit to get merged into feature-ndnlp branch.
  3. Develop on top of feature-ndnlp after the merge.
  4. Upload to Gerrit as usual.

You MAY start development before the merge commit is approved, but then you'll have to deal with the rebasing mess.

#13 Updated by Eric Newberry about 4 years ago

The API and unit tests have been completed. I'm waiting on Gerrit 2254 to be merged before submitting for code review.

#14 Updated by Alex Afanasyev about 4 years ago

what's a point of waiting? Git provides enough mechanisms to update multiple commits when necessary. Rebasing or merging would not affect your new code in any way.

I cannot understand Junxiao's statements that he will need something to be meeged before he can start working on dependent code. This is not a productive development process. Working on multiple dependent commits in progress is what a lot of people including me are doing all the time.

#15 Updated by Eric Newberry about 4 years ago

  • Status changed from In Progress to Code review

#16 Updated by Junxiao Shi about 4 years ago

  • Blocked by Bug #3070: Block::remove unexpected semantics added

#17 Updated by Eric Newberry about 4 years ago

  • % Done changed from 0 to 100

#18 Updated by Junxiao Shi about 4 years ago

  • Status changed from Code review to Closed

Also available in: Atom PDF