W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

NCSA implementation of KeepAlive

From: Beth Frank <efrank@ncsa.uiuc.edu>
Date: Thu, 19 Oct 1995 20:50:07 -0500 (CDT)
Message-Id: <9510200150.AA02447@void.ncsa.uiuc.edu>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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.  

Jeffrey Mogul suggested:

> at the beginning of the connection, but the user has become VERY
> rate of an aggressive client, we should address that issue directly.
> For example (this is just an off-the-cuff idea), the server could
> return a "try again in N seconds" error code, close the TCP connection,
> and then refuse to accept a new connection from that client until
> the N seconds has elapsed. 

Our adminstrator of the www.ncsa site adamently maintains that anything
the server itself has to do to throttle back requests is too much overhead.
If the request gets through the TCP/IP accept layer, he believes you're
better off just serving the request.  

I think that searching to see if a site is on a refuse list will just
further overload the server.

> Or the server could keep the connection
> open, but simply delay reading from it (which means that the TCP
> flow-control mechanism would force the client to stop sending).

This would also agrevate the overload problem, because the server
would just be that much longer in getting to the next request.  Think
of it as if there are only n-slots for TCP connections and a new request
from someone else can't be served until one of the n-slots frees up. 
(This is a very great simplification.)

-- 
		Elizabeth(Beth) Frank
		NCSA Server Development Team
		efrank@ncsa.uiuc.edu
Received on Thursday, 19 October 1995 18:54:02 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:34 EDT