A more efficient up2date service using binary diffs
Jeff Johnson
n3npq at nc.rr.com
Sun Mar 13 22:03:51 UTC 2005
M A Young wrote:
>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.
>
>
Yep.
>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
>
>
Thanks for publishing the numbers.
73 de Jeff
More information about the fedora-devel-list
mailing list