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