Project

General

Profile

Actions

Feature #4011

closed

Unicast Ethernet Transport and Channel

Added by Eric Newberry about 7 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Normal
Category:
Faces
Target version:
Start date:
03/25/2017
Due date:
% Done:

100%

Estimated time:

Related issues 1 (0 open1 closed)

Blocks NFD - Feature #4012: Ethernet unicast configurationClosedDavide Pesavento

Actions
Actions #1

Updated by Alex Afanasyev about 7 years ago

  • Assignee set to Davide Pesavento
  • Target version set to v0.6
  • % Done changed from 0 to 70
Actions #2

Updated by Davide Pesavento about 7 years ago

  • Start date changed from 03/26/2017 to 03/25/2017
Actions #3

Updated by Davide Pesavento about 7 years ago

Actions #4

Updated by Junxiao Shi about 7 years ago

Looking at https://gerrit.named-data.net/3790 patchset3 and https://gerrit.named-data.net/3793 patchset4, similar pcap_* function calls are duplicated between EthernetTransport and EthernetChannel. Is there any way to abstract them into an implementation class?

Actions #5

Updated by Davide Pesavento almost 7 years ago

  • % Done changed from 70 to 40
Actions #6

Updated by Davide Pesavento almost 7 years ago

Junxiao Shi wrote:

Looking at https://gerrit.named-data.net/3790 patchset3 and https://gerrit.named-data.net/3793 patchset4, similar pcap_* function calls are duplicated between EthernetTransport and EthernetChannel. Is there any way to abstract them into an implementation class?

https://gerrit.named-data.net/3876 introduces PcapHelper.

There isn't an obvious choice for the level of abstraction. I've decided to keep the PcapHelper class independent of the data-link type (DLT_*). Therefore, the class doesn't know anything about frame structures, ethernet, or any other link-layer protocols. It just wraps a pcap_t handle in a RAII class with a slightly higher-level (more C++-like) interface. Ethernet-specific routines that are reusable can be moved to face/ethernet-protocol.{cpp,hpp}.

Another question is: how can consumers access the raw pcap_t pointer?

  1. implicit conversion via operator pcap_t*()
  2. overload operator*()
  3. member function getHandle()
  4. don't provide external access to the raw pcap_t* (this implies that PcapHelper must wrap all libpcap functions that we use)
Actions #7

Updated by Davide Pesavento almost 7 years ago

  • % Done changed from 40 to 60
Actions #8

Updated by Davide Pesavento almost 7 years ago

  • % Done changed from 60 to 90
Actions #9

Updated by Davide Pesavento almost 7 years ago

  • Related to deleted (Feature #4012: Ethernet unicast configuration)
Actions #10

Updated by Davide Pesavento almost 7 years ago

Actions #11

Updated by Davide Pesavento almost 7 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 90 to 100
Actions

Also available in: Atom PDF