Bug #2438
closed
StatusDataset does not change
100%
Description
I cannot yet track down on the exact cause of the problem, but the highlights. This could be a combination of pre-existing issue with SegmentPublisher and new CS implementation
Run
nfd-status
... wait some time
nfd-status
Expected
Face list changes from time to time (at least it should show nfd-status own face)
Actual:
Face list and other things (except ServerStatus) stay the same
Updated by Alex Afanasyev about 9 years ago
From what I observing, SegmentPublisher doesn't set FreshnessPeriod.
I think in previous CS implementation this was treated as "stale" packet. Right now it is most likely treated as never stale packet. This effectively prevents getting any new data packet using status dataset protocol / segment fetcher.
Updated by Alex Afanasyev about 9 years ago
- Category changed from Core to Tables
I just confirmed that setting FreshenssPeriod=1ms on data packets published by the SegmentPublisher fixes the problem.
I declare that this is the issue with the new content store.
Updated by Junxiao Shi about 9 years ago
- Subject changed from Status datasets (based on SegmentPublisher) are effectively broken to StatusDatasets does not change
- Category changed from Tables to Core
- Assignee deleted (
Junxiao Shi) - Priority changed from Immediate to Urgent
ContentStore is correct.
From http://named-data.net/doc/ndn-tlv/data.html#freshnessperiod:
When FreshnessPeriod is omitted, the Data packet cannot be marked stale.
A Data packet without FreshnessPeriod field is never stale. Its effective FreshnessPeriod is infinite.
SegmentPublisher needs to set FreshnessPeriod.
The FreshnessPeriod shall be an argument, whose default is 5 seconds.
Updated by Junxiao Shi about 9 years ago
- Subject changed from StatusDatasets does not change to StatusDataset does not change
- Assignee set to Anonymous
- Estimated time set to 2.00 h
I'm assigning this to @Steve because he is the original author of SegmentPublisher in commit:9f6c3642ceb8bb29e38549ae916019ac89612569
The challenge here is how to make a test case.
Updated by Anonymous about 9 years ago
- Status changed from New to In Progress
I think the test case should just check that FreshnessPeriod has been set to the specified value.
Updated by Anonymous about 9 years ago
- Status changed from In Progress to Code review
- % Done changed from 0 to 70
This problem is clearly my fault (pretty sure I violated the original task spec), but it got me thinking about the ndn-cxx Data constructors. What's the motivation for unlimited lifetime being the default behavior?
It seems that application developers should be carefully considering the freshness period of their data (just like they do with name structure). Would it be better to make freshness a constructor argument? Possibly with some short (e.g. 1ms) default value?
Updated by Alex Afanasyev about 9 years ago
2Steve. we can discuss that during the call today.
In general, I'm very curisois why exactly it was working before. Was my guess anout different behavior in CS correct or there are other pieces involved?
Updated by Anonymous about 9 years ago
Is this the root of the behavior? (as of commit 27533da4f13e20dc8f7b0f5cf531d3b65b2e94e4)
void
Entry::updateStaleTime()
{
m_staleAt = time::steady_clock::now() + m_dataPacket->getFreshnessPeriod();
}
I'm guessing getFreshnessPeriod() returns -1, so the packet was already stale. The new CS entry checks that getFreshnessPeriod() is positive in updateStaleTime(), else maxes out the stale time.
Updated by Junxiao Shi about 9 years ago
- Status changed from Code review to Closed
- % Done changed from 70 to 100
Verified on NDN6.TK node