rsync and debian -- summary of issues

[Donovan Baarda]

On Fri, Apr 12, 2002 at 01:28:01PM +1000, Martin Pool wrote:
> On 12 Apr 2002, Brian May <bam at debian.org> wrote:
> 
> > I think some more details is required regarding rproxy.
[...]
> > AFAIK, it solves all the problems regarding server load discussed in
> > rsync, doesn't it???
> 
> Why did you think that?
> 
> rproxy addresses a rather different problem to rsync: for example, it
> transfers only one file at a time, not whole directories.  No, rproxy
> does not have a magic way to do the delta computation in zero time.
> Compared to rsync, rproxy has the advantage of cleaner code (imho),
> but the disadvantage that no optimization work has been done.

The big problem with rproxy is it's implemented in perl (perl: crypto for
algorithms). librsync on the other hand is a nice piece of work and _should_
be used for a re-implementation of rproxy and/or rsync.

I have recently got sponsorship to add a python front-end to librsync as an
extension to my pysync code, which I should have done by end of next week.
After this I will probably do some work on adding rproxy http extensions
into something like medusa or twisted.

If rproxy includes the signature in a HEAD responce, and supports ranged
requests, delta calculation can be moved to the client with no changes to
rproxy as follows;

1) client sends HEAD request to get upstream signature.
2) client does reverse-delta calculation.
3) client applies reverse-delta using ranged-requests to fetch required
parts from upstream.

You touched on this in your page, but not in relation to rproxy. I believe
the client-side delta stuff you mentioned was not using rproxy http
extensions at all, just adding some sort of cgi that returns signatures for
objects on the server.

-- 
----------------------------------------------------------------------
ABO: finger abo at minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------