On Fri, 30 Apr 2010 01:01:59 EDT erik quanstrom <quans...@quanstro.net> wrote: > > If the sender->receiver pipe can hold N bytes and the sender > > is streaming (that is, keeping the pipe full), the sender > > *will* be ahead of the receiver by N bytes. So a *streaming* > > protcol has to allow it to be N bytes ahead. > > i don't think this is the normal definition. > > > Even if you have one ack per message, in a sliding window of > > N messages (or bytes), the sender is allowed to get ahead of > > the receiver by upto N more messages (or bytes). Here I am > > not concerned about in-order delivery (though typically > > people assume this when they talk about sliding windows). > > a sliding window is just a particular implementation what's > required is many messages in flight.
I was using sliding window as a shorthand for "allowing the sender to be N bytes or messages ahead without regard to sequencing" but yes, the definition I used is not the generally accepted defn so I will use yours! > i don't see any reason why 9p couldn't use some of the same > congestion control ideas. the trick would be to feed back packet loss > detection and retransmission info to the point where file io gets > turned into rpcsâthe mount driver Agreed -- sort of what I meant by "I hope 9p evolves". Though I'd probably stick this in a layer below 9p. It can backpressure a 9p client if it tries to send too much (either by blocking or returning with equiv of EWOULDBLOCK).
