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

Re: HTTP Session Extension draft

From: Daniel W. Connolly <connolly@beach.w3.org>
Date: Thu, 06 Jul 1995 16:16:25 -0400
Message-Id: <199507062016.QAA08314@beach.w3.org>
To: Chuck Shotton <cshotton@biap.com>
Cc: Jeffrey Mogul <mogul@pa.dec.com>, Alex Hopmann <hopmann@holonet.net>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
In message <v02120d02ac21d6eccd15@[]>, Chuck Shotton writes:
>The last thing I want to do with a resource-constrained server is
>re-implement the nightmare of hundreds of blinking cursors in otherwise
>idle telnet sessions. The HTTP protocol is primarily connectionless
>(stateless) for reasons of efficiency from the server's perspective. I
>think a persuasive argument can be made for keeping a stream open while all
>of the required parts of a single "page" are transmitted. Allowing an
>individual to monopolize a scarce resource for longer periods of time, on
>the off chance that a human might select another link to your site from the
>page he just received, IS irresponsible.

Anybody from the MIT TechInfo project around? I read one of their
papers one time -- or maybe it was just a random posting that sounded
good. Anyway, they had a large body of real data that suggested some
nearly optimal time limit for TCP connections in their information
system.  20 seconds rings a bell.

Clearly, this needs to be a policy set by the information provider.
Many of them -- most or all in the near term -- will close the
connection immediately after each request. But folks that want to
optimize perceived performance will go for longer timeouts.  A
heuristic like "less than 10 seconds will be a noticeable performance
loss for your readers, and more than 50 (or 100) seconds will probably
_not_ be a noticeable performance increase" is probably a good thing.

Received on Thursday, 6 July 1995 13:19:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:14 UTC