At 10:46 AM 9/8/2010, Tim Bruijnzeels wrote:
<snip>
FYI: we publish everything to a new, empty directory. When this is done
we change the symlink that points to the 'current' directory, to this
new dir. Rsync follows the symlink. I believe this is similar to other
implementations.
This does not prevent mid-transfer issues as such, but.. the change
itself is fairly atomic. In other words if the RP suspects a
mid-transfer update may have occurred, and then restarts the transfer:
they should get a consistent view.
Since the manifest is always updated when changes occur, and a new EE
certificate issued with not-before time set to the moment of
publication, the RP can re-fetch the manifest and check whether it was
updated.
So, when processing the SIA for a cert:
1) get manifest (follow manifest pointer)
2) get all other objects (follow dir pointer)
3) get manifest again and compare to 1
--> if 3 and 1 don't match, wait a moment and repeat.
I am not sure though whether this enough.. other ideas?
I think this sounds good. I tried a little experiment on a Linux
machine using simply renaming of a directory while another process was in
that directory. The second process was not disturbed. I think, therefore,
one could do the following at the rsync target machine where the rsync
target directory is named, say, xxxxx:
1. Create a new directory named, say, newxxxxx as a sibling to xxxxx.
2. Fill newxxxxx with the new material for rsync.
3. Rename xxxxx to oldxxxxx.
4. Rename newxxxxx to xxxxx.
Anyone connected to xxxxx before step 3 will remain connected to
oldxxxxx and get old data. Anyone starting rsync between steps 3 and 4
will get nothing -- or some signal that xxxxx is unavailable. Anyone
starting after step 4 will get the new data. (I'm not sure that newxxxxx
has to be a sibling of xxxxx, but I haven't tried anything different.)
Charlie Gardiner
Cheers
Tim
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
