IPP Mail Archive: RE: IPP> Re: NOT - ISSUE 04 in the IPPGET

IPP Mail Archive: RE: IPP> Re: NOT - ISSUE 04 in the IPPGET

RE: IPP> Re: NOT - ISSUE 04 in the IPPGET spec [Printer closing o utbound channel connection only]

From: Carl Kugler (kugler@us.ibm.com)
Date: Mon Aug 13 2001 - 15:51:21 EDT

  • Next message: Bergman, Ron: "RE: IPP> NOT - IPPGET Issue 11: idea to allow Printer to increase server-directed polling time (on a Subscription object basis)"

    If the TCP server (Printer) closes the connection, it has to keep the
    connection around in the TIME_WAIT state for two times max time-to-live,
    (four minutes).

         -Carl

    >
    >-----Original Message-----
    >From: Marty Joel [mailto:mjoel@netreon.com]
    >Sent: Saturday, August 04, 2001 5:00 AM
    >To: ipp@pwg.org
    >Subject: Re: IPP> Re: NOT - ISSUE 04 in the IPPGET spec [Printer closing
    >outbound channel connection only]
    >
    >
    >
    >
    >Hi Tom, Ira, et al,
    >
    >
    >Connection closing is a keep-alive issue. Why does it matter who closes
    >the connection or when, as long as it is closed correctly (through the TCP
    >close handshake)?
    >
    >
    >Marty
    >
    >
    >
    >
    >
    >
    >"Hastings, Tom N" <hastings@cp10.es.xerox.com>@pwg.org on 08/03/2001
    >05:26:12 PM
    >
    >
    >Sent by: owner-ipp@pwg.org
    >
    >
    >
    >To: "ipp (E-mail)" <ipp@pwg.org>
    >cc:
    >
    >
    >Subject: IPP> Re: NOT - ISSUE 04 in the IPPGET spec [Printer closing
    > outbound c hannel connection only]
    >
    >
    >
    >Ira McDonald was having trouble with his email, so here is his response to
    >Carl Kugler comment about the Printer closing the outbound half of the
    HTTP
    >session only.
    >
    >
    >So OK if the IPPGET spec doesn't mention outbound channel and says just:
    >
    >
    >The Printer in Get-Notifications MUST ALWAYS let the Notification
    >Recipient close the connection, unless a long timeout expires at
    >the Printer. That timeout needs to be long enough for the client to
    >receive
    >a response.
    >
    >
    >Tom
    >
    >
    >-----Original Message-----
    >From: McDonald, Ira
    >Sent: Thursday, August 02, 2001 08:57
    >To: Hastings, Tom N; McDonald, Ira
    >Subject: RE: FW: IPP> NOT - ISSUE 04 in the IPPGET spec
    >
    >
    >Hi Tom,
    >
    >
    >No - closing the outbound half of the HTTP session and underlying
    >TCP connection is failure prone and is not even supported anymore
    >by some OS libraries (TCP is the only transport protocol with
    >half-connections modelled).
    >
    >
    >The Printer in Get-Notifications should ALWAYS let the Notification
    >Recipient close the connection (unless a long timeout expires at
    >the Printer).
    >
    >
    >Cheers,
    >- Ira
    >
    >
    >-----Original Message-----
    >From: Carl Kugler [mailto:kugler@us.ibm.com]
    >Sent: Tuesday, July 31, 2001 11:27
    >To: Hastings, Tom N
    >Cc: Lewis Harry (E-mail); Parra, Hugo (E-mail); Michael Sweet (E-mail);
    >Ted Tronson (E-mail)
    >Subject: Re: FW: IPP> NOT - ISSUE 04 in the IPPGET spec
    >
    >
    >>ISSUE 04: OK to clarify that a client or a Printer MAY disconnect the
    >>underlying transport connect for any operation, including the Event No
    >Wait
    >>Get-Notifications operation and the Event Wait Get-Notifications
    operation
    >>when the Printer isn't willing to honor the initial request or reneges in
    >a
    >>later response?
    >
    >
    >>So a client could keep the connection open for multiple Event No Wait
    >>Get-Notifications. Before a Printer disconnects it needs to wait enough
    >>time to make sure that any IPP response has had time to get back to the
    >>client before disconnecting, otherwise the client might not see the
    >>response.
    >
    >
    >Preferably, the Printer should close only the outbound half of the
    >connection. The client, reading the final response and getting the close,
    >should then close the entire connection.
    >
    >
    > -Carl
    >
    >
    >
    >



    This archive was generated by hypermail 2b29 : Mon Aug 13 2001 - 15:53:25 EDT