I think there is a use case, say offline message, will happen such problem.
For example, Node2 (running with IM Usage) stores an offline message at
NodeX for Node1 (also running with IM Usage) due to Node1 not on the overlay
currently. Next, Node1 joins the overlay and fetches its offline message
from NodeX, then removes that offline message stored by Node2 previously.
The remove operation is completed via StoreReq based on RELOAD base spec. If
Node1's clock is wrong and slow one hour so that the “storage_time” value
of StoreReq sent by Node1 for removing that offline message is smaller than
the previous storage time sent by Node2 for keeping that offline message.
Well, the later StoreReq for removing that offline message will fail. Within
this hour, as long as Node1 leaves and joins, it will get those undeleted
offline messages. How to solve such problem cased by clock asynchronization?
Thanks a lot.
_____
From: [email protected] [mailto:[email protected]] On Behalf Of
Eric Rescorla
Sent: Monday, March 01, 2010 10:59 AM
To: 沈婉婉
Cc: [email protected]
Subject: Re: [P2PSIP] Question about the synchronization of storage time
2010/2/28 shen <[email protected]>
Dear All,
I would like to ask a question about the synchronization of storage time for
Store Request.
For a Store Request , “storage_time” field is used to prevent rollback
attacks. But if there are more than one peer to store the same resource ,
there may be some problem of synchronization.
Foe example, if node1’s clock is faster than node2s’ and node 1 has stored
the resource which the storage time followed node1 ‘s clock. When node 2
stores the same resource, it is possible that the “storage_time” value of
“NEW” Store Request is smaller than the previous storage time. How does it
synchronize the clocks? Is there any mechanism to avoid the situation?
In general, RELOAD attempts to segregate data from separate nodes so this
doesn't happen much.
However, if it does happen, then either node2 can update its clock correctly
if its wrong
do an effective remove (store with the storage time that's ahead of node1
but a lifetime
of zero). I'm not sure if RELOAD explicitly says that a subsequent store
with the right
lifetime should succeed, but I think that would be a good rule.
-Ekr
本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。
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
