Activity
From 04/01/2016 to 04/30/2016
04/28/2016
- 12:08 PM Task #3590 (Closed): MemoryContentCache: Support setInterestFilter
- Changes merged to master in all libraries.
04/27/2016
- 03:38 PM Task #3606 (Closed): Set the Interest nonce before saving in the PIT
- Changes are committed in all libraries.
04/26/2016
- 09:27 PM Task #3606: Set the Interest nonce before saving in the PIT
- Thanks! I'll reply to the email.
- 12:49 PM Task #3606: Set the Interest nonce before saving in the PIT
- I asked this in an email to Junxiao, who said:
From protocol point of view, the Nack must be able to locate the co... - 12:10 PM Task #3606: Set the Interest nonce before saving in the PIT
- Just a quick question: Why is it important to compare the nonce of the NACK with the nonce in the PIT? Isn't it enoug...
04/25/2016
- 01:21 PM Task #3606 (Closed): Set the Interest nonce before saving in the PIT
- expressInterest makes a copy of the supplied Interest. But currently the nonce is only set when in the wire encoding....
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....
- 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?) ...
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...
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?
- 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?
- 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... - 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...
- 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... - 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 ...
- 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... - 01:27 PM Bug #1517 (Closed): registerPrefix adds the onInterest callback even when registration fails
- The fix is merged to master in all libraries.
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...
- 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...
- 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 ...
04/07/2016
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...
- 02:43 PM Task #3590 (Closed): MemoryContentCache: Support setInterestFilter
- The Face API has been updated to support setInterestFilter, separate from registerPrefix. MemoryContentCache should s...
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.
Also available in: Atom