[PATCH 4 of 4 V2] obsolete: allow cycles

[Jun Wu]

Excerpts from Augie Fackler's message of 2017-03-23 17:53:39 -0400:
> On Wed, Mar 22, 2017 at 1:42 AM, Jun Wu <quark at fb.com> wrote:
> >> As for alternatives, a correct solution needs to refer to the marker it is
> >> replacing. Since cycles should be rare, can we record the full "replaced
> >> marker" data inline in the new marker? In local storage, that could be an
> >
> > If "markers being replaced" are explicitly recorded, you will miss remote
> > markers that can be possibly replaced because you don't know them at the
> > time appending a new local marker. So you end up with some "conflict
> > resolution" logic during exchange.
> >
> > That is not very different from just using the offsets - since obsstore is
> > append-only, new markers just "replace" old ones (I don't think there is an
> > exception that the newly added marker is intended to be replaced by a
> > previous one when working locally). It's simpler but has the same exchange
> > headache.
> 
> I wonder: could we get away from using dates by putting some kind of
> generation number in the marker? So if a marker would create a cycle,
> we increment its generation number relative to the previous highest
> value in the cycle.

The problem is you don't know if a marker will create a cycle (or should
invalidate another marker), because remote markers are unknown. If you do
that during exchange, it makes exchange more complex.

I think that is not very different from just using the offsets.

Basically, if the new filed which is meant to be spread globally, date is
probably the best option. If it is not meant to be spread globally, offset
is already a decent choice, without format change. But offsets brings up
the exchange headache.

marmoute preferred date to offsets. And I agree because I don't have good
idea to handle the exchange headache (or I think it's better to be fully
automatic).

> It still means a bad actor can produce a hard-to-defeat cycle (sort
> of), but it solves the clock skew issue.

For clocks going backwards, we can detect that, say we get
maxdate = max(m.date for m in markers), then if we are going to write a
marker with date < maxdate, we could warn people, and/or write 
(date+rand(0 to 1)) as a fake date. That would at least make non-exchange
experience always expected.