NDN-CCL

04/22/2016

04:01 PM Task #3446: NDNLPv2 support

Currently, expressInterest has the onData and onTimeout callbacks. To support network Nack, we need another callback.... Anonymous

03:32 PM Task #3446: NDNLPv2 support

Andrew Brown wrote:
> We tried 0.4 but had some startup issues (a BerEncoding exception coming from libcryptopp?) ... Andrew Brown

04/21/2016

11:12 AM Feature #2075: The library should have an API to inform the application when the connection is lost to the forwarder

Andrew Brown wrote:
> We already have getIsConnected() in there; could we use that?
AsyncTcpTransport.getIsConnec... Anonymous

04/20/2016

04:45 PM Feature #2075: The library should have an API to inform the application when the connection is lost to the forwarder

But that's on a Transport and you need access to that information at the Node level? Andrew Brown

04:43 PM Feature #2075: The library should have an API to inform the application when the connection is lost to the forwarder

We already have getIsConnected() in there; could we use that? Andrew Brown

03:12 PM Feature #2075: The library should have an API to inform the application when the connection is lost to the forwarder

Andrew Brown wrote:
> Jeff Thompson wrote:
> > In the simplest case of a consumer (without register prefix), expres... Anonymous

03:03 PM Feature #2075: The library should have an API to inform the application when the connection is lost to the forwarder

We need some kind of callback. But the more I think about it, the onNack callback from expressInterest is really supp... Anonymous

02:00 PM Feature #2075: The library should have an API to inform the application when the connection is lost to the forwarder

Jeff Thompson wrote:
> Perhaps there is a fancier solution using network Nack (which I'm working on implementing i... Andrew Brown

01:56 PM Feature #2075: The library should have an API to inform the application when the connection is lost to the forwarder

One more comment about that last: if we do reconnect sockets and do re-register prefixes, it seems like there should ... Andrew Brown

01:53 PM Feature #2075: The library should have an API to inform the application when the connection is lost to the forwarder

Jeff Thompson wrote:
> I agree that something would be better than nothing, but I'll brain dump the concerns I hav... Andrew Brown

01:27 PM Bug #1517 (Closed): registerPrefix adds the onInterest callback even when registration fails

The fix is merged to master in all libraries. Anonymous

04/19/2016

12:08 PM Feature #2075: The library should have an API to inform the application when the connection is lost to the forwarder

... of course for the case of the consumer, the simplest solution when the application calls expressInterest is where... Anonymous

11:25 AM Feature #2075: The library should have an API to inform the application when the connection is lost to the forwarder

I agree that something would be better than nothing, but I'll brain dump the concerns I have which have made me procr... Anonymous

10:10 AM Feature #2075: The library should have an API to inform the application when the connection is lost to the forwarder

Jeff, I have some new thoughts about this: it seems that option 1 above seems a common enough case that we could add ... Andrew Brown

04/07/2016

09:39 AM Task #3590 (In Progress): MemoryContentCache: Support setInterestFilter

Anonymous

04/06/2016

03:09 PM Task #3590: MemoryContentCache: Support setInterestFilter

I updated the proposal to specify the filter prefix in a separate setInterestFilter method instead of the constructor... Anonymous

02:43 PM Task #3590 (Closed): MemoryContentCache: Support setInterestFilter

The Face API has been updated to support setInterestFilter, separate from registerPrefix. MemoryContentCache should s... Anonymous

04/05/2016

02:53 PM Bug #2572 (Closed): NDN packet does not define Interest.Selectors.AnswerOriginKind and it should not be used in the code

This should have been closed when #2624 was closed. AnswerOriginKind was removed. Anonymous