It wouldnt. Wouldnt increase OR decrease congestion. Would make the user
experience of IRC a lot better.....just as many of the undernet
innovations has in the past.
On Mon, 7 May 2001, Richard Smith wrote:
> ... and that would account for internet congestion how?
>
> --
> Richard T Smith (aka xplora or wakco on Undernet IRC Network)
> Technician, Media Design School
> Official CService Admin, Undernet Channel Service Committee
> ----------------------------------------------------------------------------
> Work: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Undernet: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Home: [EMAIL PROTECTED], [EMAIL PROTECTED]
> --
> Personal Disclaimer: this email is from my own thoughts and opinions and
> unless otherwise stated does not represent Undernet, CService, or Media
> Design School.
>
> > From: <[EMAIL PROTECTED]>
> > Date: Fri, 4 May 2001 13:21:47 -0400 (EDT)
> > To: Perry Lorier <[EMAIL PROTECTED]>
> > Cc: Kev <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
> > Subject: Re: [Coder-Com] CNOTICE and CPRIVMSG
> >
> > I understand your intentions of disconnecting flooders. I am just
> > suggesting that you use time stamps with your CLIENT_FLOOD threshold. So
> > that if a client's receive queue exceeds a certain amount of bytes in a
> > given period of time, then disconnect it.
> >
> > That way the client can pace the amount of data it sends, without having
> > to do it heuristically.
> >
> > Onn Fri, 4 May 2001, Perry Lorier wrote:
> >
> >> On Wed, May 02, 2001 at 11:30:59AM -0400, [EMAIL PROTECTED] wrote:
> >>> Thanks for clearing that up.
> >>>
> >>> How should a client be programmed such that the receive queue never grows
> >>> above CLIENT_FLOOD? Should it control the amount of text per given time?
> >>> The client has no knowledge of how large the receive queue is on the
> >>> server.
> >>>
> >>
> >> We could remove clients from the read list when their recieve q has filled
> >> up.
> >> But the point of client_flood was to catch clients that were flooding and
> >> disconnecting them :)
> >>
> >>
> >
>
>
