Subject: IPP> Connection Maintenance in IPP

From: Daniel Cogswell <[email-masked]>
Date: Wed, 2 Jul 1997 18:40:35 -0400

I've been working on a prototype that uses the IPP and I have run into a
question which I would be interested in hearing some comments on.

I think of HTTP as not being a connection oriented protocol. I know I'm using
the term loosely here, but, as I understand it, when you open up a connection
using http you can write and then you can read once. You can't do the
read/write read/write kind of activity.  There is, however, the CreatePrintJob
command in IPP which wants to maintain a connection. That is, it wants this
read/write read/write connection. How does IPP plan to maintain the connection
when it begins to append documents to the job?

Dan Cogswell
http://swan.penn.boulder.ibm.com

---

From: Randy Turner <[email-masked]>
Date: Wed, 02 Jul 1997 15:47:09 -0700

In its current incarnation, IPP relies on HTTP 1.1, which by default
maintains persistent TCP connections between HTTP client and HTTP
server. The client and/or server keeps a cache of open connections
between clients and servers for a period of time, so they can be
reused for subsequent requests. The cache lifetime for TCP connections,
as well as the total number of concurrent TCP connections maintained,
is implementation dependent.

With persistent connections a client can make as many requests and
receive as many responses as it wishes prior to the closing the
connection. NOTE: the server or the client may elect to close a
connection so both client and server should be prepared to handle
an unexpected connection close operation.

Randy

-- 
Randy Turner

---

From: Carl-Uno Manros <[email-masked]>
Date: Wed, 2 Jul 1997 16:26:14 PDT

>http://swan.penn.boulder.ibm.com

Dan,

this is an addition to the reply you already got back from Randy about HTTP
1.1.

The Create-Job operation, if successful, always returns a job URI.  You
will use that URI to post any further documents (Send-Document) or
print-by-reference URIs (Send-URI) that belong to that job, even if you do
it in a new HTTP connection. In effect you will probably have to make it in
a new connection as the job URI is different from the Printer URI, that you
use for the Create-Job.

Carl-Uno

Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]

---

From: "Scott Lawrence" <[email-masked]>
Date: Thu, 03 Jul 1997 08:39:34 -0400

>>>>> "RT" == Randy Turner <[email-masked]> writes:

RT> In its current incarnation, IPP relies on HTTP 1.1, which by default
RT> maintains persistent TCP connections between HTTP client and HTTP
RT> server.

RT> With persistent connections a client can make as many requests and
RT> receive as many responses as it wishes prior to the closing the
RT> connection. NOTE: the server or the client may elect to close a
RT> connection so both client and server should be prepared to handle
RT> an unexpected connection close operation.

  To expand on that just a little...

  Either side may indicate that a connection is closing so that the
  close need not be unexpected.  The client may send

    Connection: close

  in a request to indicate that the server should close the connection
  after sending the response, or the server may send the same header
  in a response to indicate that the connection will be closed after
  this response and so may not be used for the next request.

  In the absence of the 'Connection: close' header, the connection
  should remain open (though if idle it may be closed by either side
  after some timeout).

  HTTP/1.1 shouldn't maintain lots of connections to the same server
  (and there is little or no benefit in doing so as a rule); from the
  spec:

    Clients that use persistent connections SHOULD limit the number of
    simultaneous connections that they maintain to a given server. A
    single-user client SHOULD maintain AT MOST 2 connections with any
    server or proxy.

--
Scott Lawrence           EmWeb Embedded Server       <[email-masked]>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/