Re: NCSA implementation of KeepAlive (fwd)

Beth Frank (efrank@ncsa.uiuc.edu)
Fri, 20 Oct 1995 14:22:10 -0500 (CDT) 

Sorry, I forgot to cc the working group again...

	-Beth

Forwarded message:
> From efrank Fri Oct 20 10:53:31 1995
> Subject: Re: NCSA implementation of KeepAlive
> To: dmk@allegra.att.com (Dave Kristol)
> Date: Fri, 20 Oct 1995 10:53:32 -0500 (CDT)
> In-Reply-To: <199510201338.IAA11343@newton.ncsa.uiuc.edu> from "Dave Kristol" at Oct 20, 95 09:35:03 am
> X-Mailer: ELM [version 2.4 PL23]
> MIME-Version: 1.0
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
> Content-Length: 2271      
> 
> I've talked to some of our client people and they don't
> have any problem with dropping the "max" and "timeout" 
> fields.  The only information they are currently using
> is the "Connection: Keep-Alive" header.  One person did
> indicate that the information could be used for optimizations,
> but doubted that the overheard and programming effort would
> be worth the gains.
> 
> If "max" and "timeout" are removed, we'll make the change
> in our server.
> 
> 	-Beth
> 
> > efrank@ncsa.uiuc.edu (Beth Frank) wrote:
> >   > In response to some of the questions that were sent early
> >   > last week...
> >   > 
> >   > "timeout" is idle time.
> >   > 
> >   > We decided that the server needed to set a maximum number of
> >   > requests and a maximum idle time on the connection to prevent
> >   > a client from "hogging the server" and protect against denial
> >   > of service request.  The client folks thought it could be useful
> >   > to have the information on the limits, so we send it.  I'm not
> >   > sure whether they change their behavior based on the values or
> >   > not.  To get around some Mac TCP/IP peculiarities, we did work
> >   > out that each additional request from the client had to include
> >   > the "Connection: Keep-Alive" header or the server will assume
> >   > it is the last request and close connection after serving the
> >   > request.  
> > 
> > I would like the client folks to tell us what they actually do with the
> > information the server returns.  I agree it's important to prevent a
> > client from hogging a server, but that's easily accomplished:
> > 
> > 1) The server can always, as a last resort, break the connection.
> > 2) The server can fail to return a Connection: Keep-alive response header,
> > and the client will (should) know that the connection will close.
> > 
> > So the number-of-connections information in the Keepalive response
> > header is redundant.  And I've also previously stated my skepticism
> > about the worth of the idle-time piece of Keepalive.
> > 
> > (Oh, and Roy, I failed to rise to your bait about other aspects of your
> > description of Keep-alive in the spec. because I've been real busy, and
> > I probably don't understand the issues well enough to be upset. :-)
> > 
> > Dave Kristol
> 
> -- 
> 		Elizabeth(Beth) Frank
> 		NCSA Server Development Team
> 		efrank@ncsa.uiuc.edu
> 


-- 
		Elizabeth(Beth) Frank
		NCSA Server Development Team
		efrank@ncsa.uiuc.edu