Task #2077
closedPrevent reset interest from being satisfied be cached content
0%
Description
Reset interest should be propagated to all participants in a sync group. However, a data packet that is cached in the network may prevent the reset interest from being further propagated.
One solution could be assigning a unique name to each reset interest.
However, this solution may prevent reset interest to be merged in the network, thus an end user may receive a lot of reset interests.
Another solution to this problem could be using implicit digest. The idea is like this:
Ideally, there should not be any response to a reset interest, but if there is a response, the response should be exactly as what the end user requires to be.
In this case, the response should have 0 FreshnessPeriod, which means the response should not be cached in the network.
Therefore, the end user, before sending a reset interest, should construct the expected response and calculate the digest of the response.
The reset interest must carry the digest as the implicit digest.
As a result, the end user either does not receive any response or receive a response with FreshnessPeriod 0.
An reset data packet should look like this:
Name: /<sync_group_sync_prefix>/reset/[round_num] / (implicit_digest)
MetaInfo: FreshnessPeriod = 0
Content: (empty)
Signature: Digest_SHA256
The round_num
indicates how many reset rounds has been done. See more details in issue #2076.
Note: we could use double hash function to avoid collision.