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

On Mon, Feb 02, 2004 at 10:50:21PM +0100, [email protected] wrote:
> On Mon, Feb 02, 2004 at 01:20:10PM -0800, Nathaniel Smith wrote:
> > On Mon, Feb 02, 2004 at 08:56:40PM +0100, [email protected] wrote:
> > > At some other time, Nathaniel Smith wrote:
> > > > I still think it is: Lets assume there are two object A and B in the same
> > > > client. They share one connection to the server. A can now block that
> > > > connection for long times by sending huge messages (the max. message length
> > > > takes several days to go over a 100MBit network). B can't send data to the
> > > > server during that time.
> > > do we have _one_ tcp-connection per client to the server? in this case messages
> > > can processed in paralel i think. so other messages (to and from the server)
> > > can send without limitation.
> 
> > I am very, very hesitant to encourage
> > clients to make multiple connections during normal operation; this is
> > ugly, may cause havoc with server memory management (the server tracks
> > object allocation by connection, so it can clean up when connections
> > go away), and just makes everything more complicated.
> i mean if different clients have different connections to the server how
> can this harm if a client sends a very big packet to the server?
> other connections will not be affected to this if you demux this big packet
> in small steps or have one thread per connection (so you can process the
> other connections while the big packet is processed.)

We were talking about the case where a single client doesn't want
to block itself out; if it starts sending a long packet, it has to
finish sending that whole packet before it can do something else, even
if the "something else" has high priority.

> > You do need some sort of managed multiplexing in some cases to avoid
> > congestion and apply backpressure, ...
> if a client sends a message that is too small or to big... the client
> just harms itself because it just congests his own connection... 
> the server cluld close the connection if here is something
> wrong in the stream or data is expected and not have received in
> a defined timeout.
> but this sould not harm other clients/connections. thats what i'm not
> understand in this question.

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.

-- Nathaniel

-- 
"On arrival in my ward I was immediately served with lunch. `This is
what you ordered yesterday.' I pointed out that I had just arrived,
only to be told: `This is what your bed ordered.'"
  -- Letter to the Editor, The Times, September 2000