> From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com]
> Here is yet another comment of interest.
> -----Original Message-----
> From: Fielding, Roy [mailto:fielding@eBuilt.com]
> Sent: Thursday, November 02, 2000 10:08 AM
> The decision on when to close is left to either side. A server will
> close the connection based on its resource-consumption requirements
> which may vary substantially based on the type of server and the
> number of clients it is intended to serve.
<snip>
> (typically under 10 seconds, though a high-activity server will
> set this to one second or turn off persistent connections altogether).
Dropping TCP/IP connections after such a short delay seems counterproductive
to me. Just because you close a link doesn't mean it goes away instantly.
It just means you send the FIN. Even when the other end ACKs the FIN, most
stacks will keep the connection around for a while, in case there's any
other traffic "en route" that might show up late, so it won't be mistaken as
being part of a future connection on the same port. This delay can run
several minutes before a connection is considered "closed", even after the
FIN, FIN-ACK sequence. About a minute is common.
Dropping a link too quickly will result in lots of these "close-wait"
connections being left around, when keeping it up (if it's likely to be used
again) would reduce not only the waiting closed connections but the overhead
in establishing new ones...for a total reduction in both bandwidth use as
well as stack resources. It seems to me that the "Connection: close" in the
HTTP headers is intended to give some clues about whether a connection will
be used again...though no guarantees, so some sort of timeout is reasonable,
but setting it a lot shorter than the close-wait timeout makes little sense
to me. You are actually reducing your available connection-handling
resources, your available I/O bandwidth and other critical resources, not
increasing them.
If servers insist on having such short timeouts anyway, I'd like to lobby
for making them settable, with upper limits in the "several minutes" range
at least. I've run into serious problems trying to debug a client with a
printer that insists that the first request arrive within 5 seconds of the
server sending the connection ACK. When I'm single-stepping my code, I
can't always guarantee that fast a response, and the resulting connection
drop by the printer makes it very tricky to debug certain parts of client
code. Working with another printer where I can set this timeout as high as
5 minutes was far easier.
Very short connection timeouts may also make the printer unusable for
printing when connections are coming from heavily-loaded multi-user systems
that run printing systems at low priority, or where the connection path
includes a satellite link...several second delays aren't uncommon in either
of those situations. The fact that a printer can handle jobs coming over a
private 100mhz ethernet from an 800mhz P-III supporting a single user says
nothing about how it will do in the Real World (tm).
-- Mike Bartman
Process Software
Principle Software Engineer
This archive was generated by hypermail 2b29 : Thu Nov 02 2000 - 15:16:22 EST