[Nfd-dev] Vehicular face design: preliminary questions

[Davide Pesavento]

Hi guys,

We recently started designing the vehicular face for NFD (basically an
ad-hoc wifi face that uses raw 802.11 frames, see #1216 and related
tasks), and we have some preliminary questions for you, to help us
plan the design and implementation phases.

1/ Is there a tentative release schedule for v0.3? Depending on it, we
can decide whether submitting for v0.3 is feasible or if we should
target v0.4 instead.

2/ A big chunk of support code that we will have to write is fairly
separate and independent from the actual V2V face and Link Adaptation
Layer, for example the location service, the GPS parser, some utility
classes to read digital road maps, and so on. These components are
prerequisites for the vehicular face but can be developed
independently. Would it be acceptable to submit them early (say for
v0.3) and have them merged, even if we realize that we're unable to
finish the face in time for that version?

3/ Our old implementation used raw AF_PACKET sockets directly and was
therefore Linux-only. We still have no interest in supporting
platforms other than Linux (and possibly Android at a later time), so
we'd like to know if we can keep using raw sockets.
If there's opposition, we might investigate using libpcap, but this
doesn't mean we will be testing the code on other platforms such as OS
X, so it may or may not work.
Another potential problem is that the V2V face may require boost
version 1.54, when asio::generic::raw_protocol was introduced.

4/ Are we allowed to use threading inside the vehicular face? (in our
old design, each V2V face creates a thread where all the "layer-2.5"
management operations are performed)

5/ [not really a question] We identified at least two functionalities
that can possibly be abstracted and factored out in a common
superclass:
    (i) NDNLP fragmentation, shared with EthernetFace;
    (ii) Duplicate data suppression, shared with EthernetFace and
MulticastUdpFace (this one might prove difficult because the
suppression mechanisms that we've developed for V2V are substantially
more complex).

We are trying to come up with an initial design proposal ASAP,
hopefully we can discuss it in person at NDNcomm.

Thanks,
Davide