>>>>>> 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
Good point - in particular for typical http servers.
What the connection document describes are typical scenarios for servers
running on multi-megabyte machines,
>From my experience, in low-level printers, running in e.g. 1-3 meg embedded
systems, the application-level connection memory footprint
is more substantial that low-level tcp connection overhead.
I think the dependency is probably both on total available memory in the
system and on the operating system and it's implementation of tcp/ip.
... So in other words the reality is more complicated than given in the
connection management document:
E.g. it states:
* Server resources (open files, file system buffers, processes,
memory for applications, memory for socket buffers for
connections currently in use (16-64Kbytes each, data base
locks). In BSD derived TCP implementations, socket buffers are
only needed on active connections. This usually works because
it's seldom the case that there is data queued to/from more
than a small fraction of the open connections.
- this would lead you to believe that a passive connection doesn't need much
memory, but
in reality you need memory for the thread that's serving the connection and
maybe for some object that's holding it's context.
I am not saying the clients should typically try to disconnect, just trying
to indicate that the
optimal strategy depends on what server the client is talking to.
Peter