>From ipp-owner at pwg.org Fri Sep 18 18:00:12 1998
Date: 18 Sep 1998 17:00:06 -0000
Message-ID: <19980918170006.24875.qmail at findmail.com>
From: "Carl Kugler" <kugler at us.ibm.com>
Subject: IPP> Re: IPP PRO HTTP Connection: close
In-Reply-To: <012001bde30a$66e8c1b0$1e0564d2 at tulip.auco.com>
To: ipp at pwg.org
Sender: owner-ipp at pwg.org
> >rturner at sharplabs.com on 09/09/98 02:17:29 PM
> >Subject: Re: PWG IPP PRO HTTP Connection: close
> >
> >I tend to follow the saying "Be conservative in what you send, and
> >liberal in whatyou accept..."Whether the text says MUST or not, IMHO
> >we should be designing clients and servers to handle a "connection:
> >close" header whenever it is received and still function normally,
> >albeit with possibly less performance. Since I am not working on a
> >client, I cannot speak for what clients are or will actually do, but I
> >do think the client end should drive the connection status, whevever
> >possible.
> >
> > Randy
>>> Yes.
> It would be more efficient if clients are conservative in keeping the
> connection up too long mainly with IPP servers
> running on systems with limited resources, such as low-end printer devices
> whose http servers can't handle too many
> connections.
>
Be careful -- things like TCP TIME_WAIT can actually use much more of a resource (such as memory) if a client opens and closes connections frequently rather than holding one connection open and reusing it.
For example, a server must remember a connection for 4 minutes after it has been closed. If you're polling for job status every 30 seconds, you'd be better off to keep the connection open.
This is explained in
"HTTP Connection Management",
http://www.ics.uci.edu/pub/ietf/http/draft-ietf-http-connection-00.txt
and its references.
-Carl
-----
See the original message at http://www.egroups.com/list/ipp/?start=4499
--
Free e-mail group hosting at http://www.eGroups.com/