IPP Mail Archive: RE: IPP> FW: Of HTTP/1.1 persistent connec

IPP Mail Archive: RE: IPP> FW: Of HTTP/1.1 persistent connec

RE: IPP> FW: Of HTTP/1.1 persistent connections and TCP Keepalive timers

From: Mike Bartman (bartman@process.com)
Date: Thu Nov 02 2000 - 15:06:32 EST

  • Next message: Jay Martin: "Re: IPP> FW: Of HTTP/1.1 persistent connections and TCP Keepalivetimers"

    > 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.
    > (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