Project

General

Profile

Actions

Feature #3179

closed

EndpointId

Added by Junxiao Shi about 9 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Faces
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
2.00 h

Description

Develop EndpointId struct in Face=LinkService+Transport API.


Related issues 4 (0 open4 closed)

Blocks NFD - Feature #3104: NDNLPv2: GenericLinkService encoding/decodingClosedEric Newberry

Actions
Blocks NFD - Feature #3168: UdpTransportClosedYukai Tu

Actions
Blocks NFD - Feature #3170: EthernetTransportClosedDavide Pesavento

Actions
Blocked by NFD - Task #3088: Refactor Face as LinkService+TransportClosedEric Newberry

Actions
Actions #1

Updated by Junxiao Shi about 9 years ago

  • Blocks Feature #3104: NDNLPv2: GenericLinkService encoding/decoding added
Actions #2

Updated by Junxiao Shi about 9 years ago

Actions #3

Updated by Junxiao Shi about 9 years ago

Actions #4

Updated by Junxiao Shi about 9 years ago

  • Blocked by Task #3088: Refactor Face as LinkService+Transport added
Actions #5

Updated by Junxiao Shi about 9 years ago

  • Category set to Faces
  • Target version set to v0.4
  • Estimated time set to 2.00 h

See #2222 note-32 answer-8 for an explanation on the necessity of NetworkAddress, and why is appears with every packet in Transport::Packet struct.

See #2222 note-45 for the design intention of NetworkAddress.

Quote from that answer:

NetworkAddress is a data structure that represents an underlying address.
It also has a special value ANY.

The exact value of NetworkAddress is unimportant because it's neither used by LinkService nor used by forwarding.
Equality of NetworkAddress is important for reassembly on a multi-access link, and for #2108.

Actions #6

Updated by Junxiao Shi about 9 years ago

commit:c2ee303880e6bfd79c107a4cda2cc28194356409 implements NetworkAddress similar to ns3::Address, but it has caused disputes, such as:

I'm confused about the NetworkAddress class, and since I can't see how it'll be used I don't know what's the best way to implement it. I'm also slightly worried about adding an overhead of 256 bytes for the two addresses to every packet.

Since all we need is equality comparison, we could do:

  1. NetworkAddress is declared as a tuple that contains: a Transport pointer, a numeric index that indicates a peer within the Transport.
  2. A Transport that is capable of multi-access links should maintain an internal map from a peer address to a numeric index.

    For example, in UdpTransport:

    1. UdpTransport has an internal map from IP+port to int is maintained.
    2. For each incoming packet, lookup its sourceIP+port in this map.
    3. If not found, insert sourceIP+port into this map, with a new numeric index (generated from an auto-increment counter).
    4. The remote NetworkAddress is a self pointer, and the numeric index in this map.
    5. Recently unused IP+port can be erased from the map.

This solution has less memory overhead than ns3::Address design, at the cost of a hashtable.

Actions #7

Updated by Eric Newberry about 9 years ago

Who will be working on this issue?

Actions #8

Updated by Junxiao Shi about 9 years ago

20150908 conference call decides to take an approach similar to note-6.

NetworkAddress is renamed to Transport::EndpointId, and is a typedef of uint64_t.

A Transport should either fit the address into the 64 bits (enough for IPv4+port or Ethernet MAC address), or use an internal map as described in note-6.

Actions #9

Updated by Junxiao Shi about 9 years ago

  • Subject changed from NetworkAddress to EndpointId
  • Description updated (diff)
  • Status changed from New to In Progress
  • Assignee set to Junxiao Shi

Design is updated in #2222 note-55.

I'll update it into the same commit as #3088.

Actions #10

Updated by Junxiao Shi about 9 years ago

  • Status changed from In Progress to Code review
Actions #11

Updated by Junxiao Shi about 9 years ago

  • Status changed from Code review to Closed
  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF