[Nfd-dev] [Ndn-app] Close NFD backdoor

[Yingdi Yu]

Hi Junxiao,

Just two quick comments about in-app storage.

On Sep 9, 2014, at 9:50 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> In-App Storage
> 
> In-App Storage provides an application-controllable Data storage within the application. The module is typically provided by the library.
> 
> Benefits:
> 
> keep the forwarder simple
> application has a chance to inspect the Data again before using it to satisfy incoming Interest
> Drawbacks:
> 
> duplication: when a Data packet is used to satisfy an Interest, it would have copies in both In-App Storage and ContentStore
This can be solved if app can tell nfd not to cache the data. Given this only happens on a localhost, it can be done by extending the local control header. Although there are some encoding/decoding overhead, we do not have change the architecture.
> risk of Data loss: when a Data packet is used to satisfy an Interest, if application chooses to delete the copy in In-App Storage, the Data would be lost when the copy in ContentStore is evicted

As the producer of the data packet, the app should be responsible for taking care of its own data. If the app wants to keep the data persistently available, it should look for some persistent storage service for that purpose, rather than relying on nfd. If the producer decides to discard a data packet, then there is no point for local ContentStore to keep it.

Yingdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140909/b12404a5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140909/b12404a5/attachment.bin>