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 > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
