Subject: Re: [P2PSIP] Issue about an impact on erroneous judgement of life time for a stored resource after resource migration

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 3 Jan 2011 17:00:00 -0500

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-masked]> 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-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>
>