Re: [Fresco-devel] [ReFresco 03] Proposed network architecture overview

Nathaniel Smith wrote:

>[hey, can you fix your quoting so it actually puts in attributions?]
>  
>
verry sorry... this is @work here so i have to write my mail under 
Moz/Thunderbird-composer...
i'll try be carefull about this in the future ;-)

>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.
>
>  
>
like a kick from the flood-protection service on irc ;-)

>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
>  
>
ok. many thanks to your answers :-)
i hope that Caprice will be a success!

cinap_lenrek