On 9/8/10 7:56 AM, Terry Manderson wrote: > Hi Steve > > On 8/09/10 8:25 AM, "Stephen Kent" <k...@bbn.com> wrote: > >> Folks, .... >> >> I have no specific proposal for the lock object, or the details of >> how RP software interpret it. I'l looking for suggestions, or an >> alternative way to address the problem. > > It sounds like system hackery, but I feel more comfortable in looking > towards recommendations about how the directory structure is laid down, > given that rsync is file based and not block based, and after a repository > is constructed then new file-lists and transfers (for a client) can be > directed at the latest repository version. Existing rsync processes would > need to stay within the state of the repository as it was when they were > started. > > Making this a server issue then removes all RP decisions except for > freshness. >
I don't know how to make this work. We do not want to re-implement or modify rsync(d) so I don't see a way to make client 'sessions' sticky to a previous state of the repository. I would be more comfortable with a client side strategy to detect problems. How about we advise clients that detect problems to re-fetch the manifest and look at the not-before time in the EE certificate? If this is too close to now for comfort (i.e. just re-issued), try again... Cheers Tim > Cheers > Terry > > _______________________________________________ > 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
