Normally storage_time doesn't really matter much. If all nodes have reasonably synchronized clocks, there should be no problem. If clocks are unsynchronized, then the only cause of concern is if a store is rejected with an Error_Data_Too_Old. In this case, the storing node should perform the store with a storage_time greater than that for the current object. I will add a clarification to this effect.
The use of storage_time is not just to prevent rollback attacks, but also to solve conflicts in the case of partitioning. Bruce On Sun, Mar 7, 2010 at 6:03 PM, World <[email protected]> wrote: > Dear all, > > So is it neccessary for a synchronization mechanism of storage time? What > do you think? > Thanks. > > --- *10/3/1 (一)，JeffreyHo <[email protected]>* 寫道： > > > 寄件者: JeffreyHo <[email protected]> > 主旨: Re: [P2PSIP] Question about the synchronization of storage time > 收件者: "'Eric Rescorla'" <[email protected]>, [email protected] > 日期: 2010年3月1日,一,下午2:06 > > 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]<http://tw.mc723.mail.yahoo.com/mc/[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]<http://tw.mc723.mail.yahoo.com/mc/[email protected]> > https://www.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > >
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
