On 28 Feb 2001, Andrew Tridgell <[EMAIL PROTECTED]> wrote:
> What I don't see is how we could recode this to avoid the zero window
> without losing a lot of the pipelining advantage we have now. Going to
> a more traditional request/response model in rsync would certainly
> make TCP like us but would incur a huge penalty in latency.
>
> As we are currently working on the design of rsync 3.0 it would be
> good to get suggestions now on brilliant ways of solving this
> problem. (please don't suggest opening a second control socket!)
So, one approach is SMUX, in which the author claims to have thought
through the potential deadlock/memory usage problems Andrew's talking
about:
http://www.w3.org/Protocols/MUX/WD-mux-980708.html
However, I'm not sure if it's better to have such a general
connection-multiplexing layer, or just to go to an async
request/response system inside the rsync 3 protocol.
--
Martin Pool, Human Resource
Linuxcare. Inc. +61 2 6262 8990
[EMAIL PROTECTED], http://linuxcare.com.au/
Linuxcare. Putting Open Source to work.
PGP signature
