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