Re: rsync3 design (was Re: Linux 2.2.16 through 2.2.18preX TCP hang bug triggered by rsync)

2001-03-18 Thread Martin Pool
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

Re: rsync3 design (was Re: Linux 2.2.16 through 2.2.18preX TCP hang bug triggered by rsync)

2001-03-18 Thread Rich Salz
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

Re: Linux 2.2.16 through 2.2.18preX TCP hang bug triggered by rsync

2001-03-17 Thread kuznet
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

Re: rsync3 design (was Re: Linux 2.2.16 through 2.2.18preX TCP hang bug triggered by rsync)

2001-03-16 Thread Martin Pool
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

rsync3 design (was Re: Linux 2.2.16 through 2.2.18preX TCP hang bug triggered by rsync)

2001-03-16 Thread Martin Pool
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 >

Re: Linux 2.2.16 through 2.2.18preX TCP hang bug triggered by rsync

2001-03-16 Thread Rich Salz
> 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

Re: Linux 2.2.16 through 2.2.18preX TCP hang bug triggered by rsync

2001-03-16 Thread Martin Pool
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

Re: Linux 2.2.16 through 2.2.18preX TCP hang bug triggered by rsync

2001-02-27 Thread Rich Salz
> 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

Re: Linux 2.2.16 through 2.2.18preX TCP hang bug triggered by rsync

2001-02-27 Thread Martin Pool
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