A more efficient up2date service using binary diffs

M A Young m.a.young at durham.ac.uk
Sun Mar 13 20:44:15 UTC 2005


On Sat, 12 Mar 2005, Jeff Johnson wrote:
> Hint: xdelta is the wrong approach, because both packages have to exist
> on either client or (more likely) server,
> leading to a combinatorial complexity of deltas to manage for all
> possible updates.
>
> Try rdiff from librsync instead.

I think it depends what you are aiming for. xdelta on the header combined
with the uncompressed cpio still gives you the minimal byte transfer,
which may be the best solution for really low bandwidth but requires both
rpms to be on the server to generate the delta, and the old rpm to be on
the client. As to which delta to store on the server the minimal bandwidth
solution would be to generate deltas to the latest rpm from each of the
preceding rpms, but this would need every rpm (or the first and
incremental deltas) to generate.

On the other hand rdiff is much more flexible at the cost of a larger
bandwidth usage. For example to generate the deltas from all the previous
rpms to the current one you just need the current rpm and signature files
from all previous rpms, not the complete rpms, so there are advantages at
the server end. Also if you could set up some sort of rdiff server which
takes a signature file and an rpm name and returns a delta, you probably
don't need any rpm on the client machine, as you could use something like
rpmrebuild to construct an rpm from installed files and send the signature
from that.

I am repeating my figures below, and adding similar figures from rdiff as
well as xdelta for comparison.

	Michael Young

libgcj-4.0.0-0.31.i386.rpm 13942525
libgcj-4.0.0-0.32.i386.rpm 13950302
xdelta of rpms              6911651
same (no compression)       7025625
xdelta of header + cpio     3723074
same (no compression)       8604163
rdiff of rpms               7310525
same (gzipped)              7159019
rdiff signature of 1st rpm    81708
rdiff of header + cpio     17870597
same (gzipped)              5582770
rdiff signature              190476




More information about the fedora-devel-list mailing list