The idea is that lifetime is time in seconds for which the data is valid. e.g. if the data is valid for one hour, it would be set to 3600 on the initial store.
Somewhere, there should be an instruction that any time a data object is transferred across the wire, this field is adjusted, but I can't find it anywhere, only: When a peer stores data previously stored by another node (e.g., for replicas or topology shifts) it MUST adjust the lifetime value downward to reflect the amount of time the value was stored at the peer. which doesn't specify a mechanism for accomplishing this. Also, there's some material in 12.5.3 which I think is really unclear as it mixes storage time and lifetime. We will try to update the text to clarify these issues. Bruce On Tue, Jan 4, 2011 at 1:20 AM, JeffreyHo <[email protected]> wrote: > 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
