On Sun 18 Jan 2004 4:47 am, Goswin von Brederlow wrote: > Andreas Metzler <ametzler@downhill.at.eu.org> writes: > > Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> wrote: > > > Doug Holland <meldroc@frii.com> writes: > > > > [...] > > > > >> because it hogs I/O and CPU cycles on the Debian servers. That's a > > >> valid reason, but surely there are ways around it. > > > > > > Its called cnysr and I asked for supporting it i think over a year > > > ago, never got a reply. > > > > > > cnysr (rsync backwards you might have noticed) reverses the roles the > > > client and server play in rsync. Instead of the client sending a > > > blockwise checksum to the server the server send them, either > > > calculated on the fly or from a precalculated file. The client then > > > checks what blocks it needs and requests those. The blockwise > > > checksums are (depending on the block size, assuming 1K) about 2% of > > > the file. > > > > [...] > > > > Hmm. Iirc in almost every discussion about apt+rsync the existence of > > a rsync-like algorthm with reversed sides (client doing the expensive > > calculation) hascome up and was always said to be patent-encumbered. > > cu andreas > > I know of no such patent and rumors of such one in US don't realy > intrest me (not being in the US and all). > > The algorithm used to find blocks that need to be downloaded is > identical to rsync, just the method of fetching them (i.e. the client > requesting instead of the server pushing) is reversed. If cnysr falls > under any patent then rsync should too. > > MfG > Goswin I'm all for this. If there's a patent on the rsync/cnysr algorithms, they can most likely be invalidated with prior art, and any company that wants to push the matter would end up looking like SCO. And I do believe that the gzip packages already have the -rsyncable option built into them.
Attachment:
pgpSmvfWSzng1.pgp
Description: signature