Release 3 of "rzync" new-protocol test
wayned at users.sourceforge.net
Fri Jun 21 03:52:02 EST 2002
For anyone who'd like to check out the latest release of my "rzync" [sic]
test release, I've just released a new version. For those that might
not have time to look at the code but could provide some feedback based
on a rough description, I've created the following simple web page:
Here's the tar file of the new release:
Changes in this version:
I've optimized the protocol to make the transferred-byte overhead
smaller; I've used an rsync-like file-list compression to make the
directory data smaller; I've gotten rid of some previous limitations
(such as the 4-byte file-size limit and the lack of reallocating various
buffers for really large file-count transfers); I've re-enabled the
"move" versions of the various get/put commands (which were disabled in
the last release); and I've fixed several bugs. The resulting program
seems to be working quite well in my limited testing.
The count of transferred bytes in the latest protocol is now below what
rsync sends for many commands -- both a start-from-scratch update or a
fully-up-to-date update are usually smaller, for instance. This is
mainly because my file-list data is smaller, but it's also because I
reduced the protocol overhead quite a bit. Transferred bytes for
partially-changed files are still bigger than rsync because librsync
creates unusually large delta sizes (though there's a patch that makes
it work much better, it's still not as good as rsync).
In my speed testing, one test was sending around 8.5 meg of data on a
local system, and while rsync took only .5 seconds, my rzync app took
around 2 seconds. A quick gprof run reveals that 98% of the runtime is
being spent in 2 librsync routines, so it looks like librsync needs to
be optimized a bit.
One potential next steps might include optimizing rsync to make the
transferred file-list size a little smaller (e.g. making the transfer of
the "size" attribute only as long as needed to store the number would
save ~4-5 bytes per file entry on typical files).
It looks like work needs to be done on making librsync more efficient.
Until I can get some better speed tests, I'm unsure if I should attempt
to make rsync talk my new protocol. Opinions welcomed.
More information about the rsync