On Tue, Dec 23, 2008 at 11:27 AM, Antoine Roly <[email protected]> wrote: > Hi, > > I have some questions about storage section in the Reload Base draft: > > Section 6 > > storage_time: The time when the data was stored in absolute time, > represented in seconds since the Unix epoch. Any attempt to store a data > value with a storage time before that of a value already stored at this > location MUST generate a 412 error. Note that this does not require > synchronized clocks: the receiving peer uses the storage time in the > previous store, not its own clock. > > What value should be used for the first store a peer receive? For the next > requests, if I'm right, the peer starts a timer every time it receives a > store, and set storage time value to [previous storage time + timer value], > isn't it? >
The storage_time is set by the node generating the store request. All the receiving peer needs to do is compare the storage_time in the new request with the one in the old. I am personally not convinced that this field adds anything to the protocol not already accomplished by the generation id, but haven't taken the time to evalaute it fully. It makes a system with multiple writers for the same value much harder. > Section 6.3.1.1 Store request definition: > > kind: The Kind-ID. Implementations SHOULD reject requests corresponding to > unknown kinds unless specifically configured otherwise. > > but a few sentences below: > > The peer MUST perform the following checks: > o The kind_id is known and supported. > [...] > If all these checks succeed, the peer MUST attempt to store the data values > [...] > > What is the correct action if I am configured to accept unknown kinds? What that means is outside the scope of the draft because the security policy for each kind varies. (but see the separate threads on agnostic or dynamic new kinds) > > For non-replica stores, if the store succeeds and the data is changed, then > the peer must increase the generation counter by at least one. If there are > multiple stored values in a single StoreKindData, it is permissible for the > peer to increase the generation counter by only 1 for the entire Kind-ID, or > by 1 or more than one for each value. > > Why allowing to increase the counter by more than one? If a node increase > the value by more than one, it could become higher than the number of time > the object has been written (which is the definition of generation_counter). > I'm not really sure why the "or more than one" is there. I don't think it would hurt the correctness, but I don't know of a reason to do it. > 0 is used by other nodes (note: which other nodes?) to indicate that they > are indifferent to the generation counter's current value. For replica > Stores, the peer MUST set the generation counter to match the > generation_counter in the message. Replica Stores MUST NOT use a generation > counter of 0. > > If I am a node indifferent to generation counter's value and I Store data, I > can set generation value to 0. What value should be used for replicas Stores > since they must no use 0? > That text is pretty unclear/wrong. "other nodes" means that it's possible for a store to say "replace the current value with this regardless of generation". Later on "in the message" should say "stored by the responsible peer." I will make a note to change. Bruce > Best regards, > > A. > > > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
