I'm not a BEEP expert. If you'd like, perhaps we can bring Kris
Magnusson into the loop.
> use it we should certainly learn from it.
Agreed.
> * There seems to be no C implementation yet. Much as I like Java and
>Python, I think rsync still needs to be done in C, and building
>this w
> Here's my current idea: it may be naïve about the TCP bugs, but I hope
> it will be more reliable and still keep both directions on the network
> maximally full.
You owe it to yourself to look at BEEP and the TCP mapping. It was
designed by folks who really know how to optimize ietf-style prot
> So, one approach is SMUX, in which the author claims to have thought
> through the potential deadlock/memory usage problems Andrew's talking
> about
Better, I think, to look at the IETF's BEEP protocol, primarily done by
Marshall Rose. In particular, the TCP mapping shows you everything you
nee
It seems to me that the irreducible note of the problem-space is
make these two files the same
Which is good, because that is also the hardest/cleverest part (the rsync
delta protocol). The need for the most flexibility is in determining the
list of files.
So we need to make sure the boun
> Would be nice if you could specify a DBM/HASH/etc file that one
> machine can create and the other 4 could read.
Without some special flag like "--trustmedontstat" (sic :) the only thing you
can can by using a database is the HASH calculation. Skim through the mailing
list archives of
> However, I don't think SSL will cope with two fork'd processes trying
> to do SSL simultaneously, because the library assumes complete control
> over the local end of the socket.
OpenSSL doesn't *have* to work that way, it's just that the default
implementation that most people use works that w
