NFD » ndn-cxx

I'm starting the Face::Impl::PendingInterestTable extension in https://gerrit.named-data.net/4097 patchset1.
I notice a problem:

In #3678, thread-safe Face frontend class encodes Data and Nack into wire format, and passes the wire encoding to single-threaded Face::Impl backend class which then sends the packet to NFD via a Transport.
If I need to find the pending Interest record that is satisfied by Data or rejected by Nack, I cannot do so in Face frontend class because it must be thread-safe. Instead, I'll have to pass Data and Nack to Face::Impl backend class, but that requires copying the Data or Nack, which leads to performance concerns.

Note that finding the pending Interest record is not only required by this issue, but also needed by #3979. In #3979, a Data passed to Face::put needs to be matched against pending Interest records to see which pending Interests received via Face::expressInterest could be satisfied.

Alex agreed with copying packet to Impl at 20170809 NFD call.

https://gerrit.named-data.net/4100 moves packet encoding to Impl class.
There is a small behavior change: if packet size exceeds limit, Face::expressInterest and Face::put may not throw exception; exception may be thrown by Face::processEvents when encoding happens.
Previously, Face::expressInterest has a packet size check on the bare Interest without NDNLP headers, but this check is unreliable because NFD side requires the whole LpPacket to stay within the limit.

https://gerrit.named-data.net/4097 patchset3 inserts pending Interest records for Interests received from the forwarder, and queries those records when the app puts a Data or Nack to the face.

In Face::Impl::putData, the querying currently can yield one of two results: either the Data matches a pending Interest from the forwarder, or there is no match. The Data goes to the forwarder in both cases, because the library should support sending unsolicited Data and allow the forwarder's policy to decide whether to reject them.
In #3979, this querying may also find the Data matching an Interest from the local app, and in that case the Data would not go to the forwarder (actually, this is already possible, but Face::Impl::putData is unlikely to be invoked if Interest was not sent to a callback in the local app).

In Face::Impl::putNack, the Nack goes to the forwarder only if it matches a pending Interest record from the forwarder. This means, it is no longer possible to transmit an unsolicited Nack.
In a later commit of this issue, this procedure will be extended to send a Nack only if all callbacks receiving the Interest has nacked.

https://gerrit.named-data.net/4173