On Wed, Sep 8, 2010 at 10:04 AM, Rob Austein <s...@isc.org> wrote:
> I don't see any locking strategy (either modifying rsync or creating a
> new RPKI object to represent a lock) as likely to work. I can go into
> details if necessary, but in short there are just too many different
> ways that a relying party could end up with a potentially inconsistent
> collection of objects, and this problem goes beyond a single directory
> ("publication point"), or the rsync protocol.
>
> I see no alternative but to place the burden of assembling a
> consistent view on the relying party. This may mean that the relying
> party's view lags the latest published data in some cases, and that a
> relying party that's just starting up (has no cache of valid results
> from previous retrieval runs) may end up with an incomplete picture
> portions of the universe. So be it.
>
> Welcome to the world of loosely consistent databases.
as an aside, rsync issues can mostly be avoided with:
morr...@donkey:~$ rsync --help | grep delay
--delete-delay find deletions during, delete after
--delay-updates put all updated files into place at transfer's end
or that sort of thing (--delay-updates) is a common thing to use in
syncing large sets of data where other parties are reliant on a
consistent view (and changing that view under them is considered
rude).
For this discussion though it strikes me that there could be lots of
reasons that an RP sees a slightly different view of the publication
point over time, different from what another RP sees, or the publisher
intends inside a short period of time at least. Checking what you
download with what is supposed to have been there (manifest checks)
are still required, or prudent at least.
-chris
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
