Good point - in particular for typical http servers.
What the connection document describes are typical scenarios for servers
running on multi-megabyte machines,
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