Re: [Fresco-devel] [ReFresco 03] Proposed network architecture overview
Nathaniel Smith <[email protected]> Wed, 4 Feb 2004 02:00:23 -0800
| Newsgroups | gmane.comp.video.fresco.devel |
|---|---|
| Message-ID | <[email protected]> |
[hey, can you fix your quoting so it actually puts in attributions?] On Wed, Feb 04, 2004 at 09:12:38AM +0100, cinap_lenrek wrote: A bit ago njs wrote: > >Clients can send each other messages; imagine the case where client A > >has a fast pipe, and client B has a slow pipe. If A starts sending > >messages to B quickly, they'll accumulate in the server. Eventually, > >the server will have to stop reading anything from client A until B's > >buffers drain, to avoid unbounded memory usage. Client A would > >generally like to avoid this, so there need to be mechanisms to allow > >flow-managed inter-client bulk data transfer. > > > you are right... if B is blocked then A will block too because the > server's pipe to B is going to be > filled and B never reads from the pipe. ok... but how you can resolve > this? and what means > "flow-managed" in practical? I'm not sure exactly; it's tricky making things safe for everyone. Basically, once B's queue fills up, you have to require it read at a certain rate or else be forcibly disconnected, to protect A from B. This is mostly just worrying about preserving correctness in edge cases; in normal usages the above situation shouldn't arise very often. It's also just not possible to do any better in general, without breaking fundamental ordering guarantees. There is one important special case though; non-timely bulk data transfer. Sometimes a client will want to get a chunk of data from one place to another, and the exact ordering wrt other operations doesn't matter too much, and there needs to be an elegant way to do this. Basically what you do in a situation like this is the "sliding window" trick; the sender sends a certain amount of data, and then waits for an acknowledgement before sending more. (This shows up all over the place... it's fundamental to TCP, the SSH protocol, etc.) For Caprice, one can accomplish this by putting a special proxy in the server, that peeks at the various client buffers involved and manages the sliding window through some special messages. (More detail forthcoming at some point; I have a few pages of notes on these issues...) -- Nathaniel -- "Of course, the entire effort is to put oneself Outside the ordinary range Of what are called statistics." -- Stephan Spender