I was also surprised at the statements made about dropping TCP connections
so quickly as being "net friendly". I thought the whole world knew that
TCP connection setup/teardown times are notoriously bad and that connections
should persist as long as possible to avoid these costs, not to mention avoiding
the pitfalls mentioned by Mike.
...jay
Mike Bartman wrote:
>
> > 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:32:09 EST