Thank Bruce's comment. But I am sorry that I didn't express my question clearly so that it might make Bruce misunderstand this issue. In a word, my question is that how the stored peer determinates whether a resource has been expired based on 'lifetime' value after resource migration. I address a scenario below. 1. Peer-1 stores a resource A with 'lifetime' of 1 hour to Peer-2. 2. After 30 mins, Peer-3 joins to between Peer-1 and Peer-2. 3. Peer-2 occurs resource migration, so Peer-2 stores the resource A to Peer-3. Please note the value of 'lifetime' is still 1 hour. 4. After 30 mins, Peer-3 can't detect the resource A to be expired because the 'lifetime' is 1 hour not 30 mins.
One solution is that Peer-3 detects whether the resource A has been expired according to compare the current time with 'storage_time' + 'lifetime'. But this will fail if Peer-3 and Peer-1 are not clock sync. The other solution is that in step 3 above, Peer-2 decreases the 'lifetime' first, then migrate the resource A to Peer-3. But this needs to add the specification in reload base. Hope I address my question more clear this time. Looking forward to receiving your further comment. Thanks a lot. Jeffrey -----Original Message----- From: Bruce Lowekamp [mailto:[email protected]] Sent: Tuesday, January 04, 2011 6:00 AM To: 何哲勳 Cc: [email protected] Subject: Re: [P2PSIP] Issue about an impact on erroneous judgement of life time for a stored resource after resource migration That timestamp is generated by the storing node, i.e. the one that creates the data in the first place. It's essentially a sequence id that can be used by the overlay to determine which of two objects is newer. It could also have simply been a monotonically increasing counter, but that would require a fetch before store every time. As the section (6) says, if a node needs to store data and finds that a supposedly newer object is stored there due to clock sync problems, the node can just add one to the value stored there. Bruce On Wed, Dec 22, 2010 at 1:13 AM, JeffreyHo <[email protected]> wrote: > Dear all, > > I would like to address an issue about erroneous judgement of life > time for a stored resource in Storage Request after resource > migration. It might be caused by asynchronized clock among peers. > > In the section of Data Storage Protocol specified in reload base, it > gives a note that "this does not require synchronized clocks: the > receiving peer uses the storage time in the previous store, not its > own clock." But it seems resulting in an impact on life time > judgement for checking the validity period for the stored data after > resource migration. If the clock is required to be synchronized for > all peers on the overlay, the validity period check can be done > dependent on both 'storage_time' and 'lifetime', even resource > migration occurred. But now the 'storage_time' can be used for such > time operation in the receiving peer, especially for resource > migration situation. An alternative is that the original responsible > peer modify the 'lifetime' in the Store Request before resource > migration for the new responsible peer so that the new peer can know how much > time the migrated resource will be expired. > > Should we specify the action of modifying the life time for Store > Request when doing resource migration in the reload base > specification? Any response is welcome. Thanks a lot. > > BR, > Jeffrey > > 本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。 > This email may contain confidential information. Please do not use or > disclose it in any way and delete it if you are not the intended recipient. > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > > ==================================================================== 本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。 This email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient. _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
