On Wed, 16 Feb 2022 at 19:49, Rob Austein <sra@hactrn.net> wrote:

On Wed, 16 Feb 2022 13:10:27 -0500, Job Snijders wrote:

...

On Wed, 16 Feb 2022 at 19:07, Randy Bush <randy@psg.com> wrote:

sra commented to me that, an rp doing protocol fall-over from rrdp to rsync, or vice versa, has to do the full download as the data structure is so different. i.e. load spike

Perhaps it doesn’t need to be a full load: “rsync ―compare-dest” (against a previously downloaded and validated set of signed objects) offers a path towards optimising the protocol fall-over.

Even assuming the RRDP client stores and believes the rsync URIs in the RRDP data stream, and further assuming that the client is clever enough to write out its RRDP-derived database into a directory tree which exactly matches an rsync filesystem layout before failing over,

The OpenBSD RPKI validator does the above, while maintaining robust cryptographic integrity (in version 7.6 and higher). I hope other validators take inspiration from this, similar to how we (OpenBSD) took inspiration from the Dragon Labs implementation. Your work lives on and on, hat tip to you Rob! :-) RRDP doesn't convey things like file modification dates that rsync

needs to perform an efficient incremental transfer, so the first rsync pass is still going to be expensive.

Not obvious to me that there's any good way to optimize this. YMMV.

Ties once pointed me at the GPL rsync “-c” (checksum) option, which makes transfers more focussed on content rather than filesystem attributes. From my (openrsync) this is still work to be done. I see a path :-) Kind regards, Job