On 18 Mar 2001, Rich Salz <[EMAIL PROTECTED]> wrote:
> > * I don't think we need multiple streams inside a single connection,
> >although perhaps this is a failure of imagination on my part.
>
> Or my confusion. I thought there were like three open TCP streams with
> bidirectional communic
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
Hello!
> What I don't see is how we could recode this
Please, remember that most of the reports are not related
to zero-window lockups. Recoding is not required at all.
In fact, we have only two reports about locking up when talking
to solaris, but lots of reports about locking due to logical l
Rich wrote:
> > 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 protocols.
> > Sliding windows, sequence numbers, all that good stuff.
It's a good paper, and an interesting design. If we don't actually
use it
On 16 Mar 2001, Rich Salz <[EMAIL PROTECTED]> wrote:
> > 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
>
> 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
On 28 Feb 2001, Martin Pool <[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 b
> 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
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 w