<[EMAIL PROTECTED]> writes:
> The rsync on-the-wire protocol is very complex. Too complex. It would
> be horrible as a written down spec.
To me, the core of it seems reasonably sound.
> Instead I suggest you look at the librsync code, which is a much
> cleaner implementation of the rsync algorithm which is the core of
> rsync. See the rproxy/librsync CVS tree on samba.org.
You don't have a source snapshot lying around? I find it difficult to
download all the files from cvsweb (or if you have a wget command that
does the trick, please tell me).
> Alternatively, if your patches are simple I would consider them for
> the main rsync tool distribution.
My primary wish for an rsync library is that it is i/o free (like
zlib). I haven't been able to figure out if librsync does that yet.
Anyway, I'll continue hacking the rsync protocol some more; perhaps it
will turn out to be a few hours waste of time, but at least I should
learn something from it.
> the mail below which I sent a few weeks ago might also interest you.
> For a couple of years people have been reporting intermittent problems
> with rsync over ssh freezing during a large transfer (typically
> several GB). I have now gotten to the bottom of these problems, and
> have written a small test program which demonstrates a deadlock in
> sshd when doing large bi-directional transfers. Luckily the problem is
> easily solved by modifying sshd to use socketpair() instead of
> pipe(). Just remove "#define USE_PIPES 1" from near the bottom of
> includes.h does the trick.
Interesting. lsh doesn't use pipe() at all; this is because I use
non-blocking i/o for everything, and then the "atomic" feature of
pipe() is very inconvenient.
I've stumbled on one linux bug, when using shutdown() on AF_UNIX
sockets, but I think it is fixed in recent kernels. Besides that,
socketpair() seems to work fine.
Regards,
/Niels
