Task #2077
Updated by Yingdi Yu over 9 years ago
Reset interest should be propagated to all participants in a sync group. However, a data packet that is cached in the network unique, otherwise someone may prevent the reset interest from being further propagated. One solution could be assigning generate a unique name non-stale response 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 (though it is like this: Ideally, there should not be any response to a reset interest, but if there is a response, allowed), and 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 will prevent following 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. from reaching others.