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

[email protected] Mon, 2 Feb 2004 22:50:21 +0100
Newsgroups gmane.comp.video.fresco.devel
Message-ID <20040202215021.GA2954@balthasar>
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:
> > > > Your DOS scenario isn't a problem either.
> > > 
> > > 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.
> 
> Not quite following this.
sorry :(

> 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.)

> 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.

> ... but I think we can best manage this
> at a higher level.