as discussed previously, I'm not convinced that concurrent connections is the (only?) thing that should be limited, or that this should be the responsibility of the client (rather than the server or an intermediary).

Server resources are becoming cheaper every day (memory / disk / CPU).  So I believe the best place to restrict usage is at the server, where the operator then has a choice about how much service will be provided.  Putting a responsibility on the client takes away this choice from the server operator.

If you made cellphones, and decided to restrict the number of calls it would make in any 1 day, do you think you'd find a telco that would sell it?

Furthermore, putting restrictions into the protocol makes it independent of application.  For instance an in-house client server system using HTTP may have no need or desire for any sort of limit.

I think therefore the best we can do is encourage implementors to act responsibly, and consider other users of the network (where there are any).

So, what about something like:

"Implementors of client applications SHOULD give consideration to effects that a client's use of resources may have on the network (both local and non-local), and design clients to act responsibly within any network they participate in.  Some intermediaries and servers are known to limit the number of concurrent connections, or rate of requests.  An excessive number of connections has also been known to cause issues on congested shared networks.  In the past HTTP has recommended a maximum number of concurrent connections a client should make, however this limit has also caused problems in some applications.  It is also believed that any recommendation on number of concurrent connections made now will not apply properly to all applications, and will become obsolete with advances in technology."

this then potentially covers any resource that should be managed, e.g. not just connections, but perhaps also bandwidth, cache space on an intermediary etc etc etc



William A. Rowe, Jr. wrote:
Mark Nottingham wrote:


Clients (including proxies) SHOULD limit the number of simultaneous
connections that they maintain to a given server (including proxies).

Previous revisions of HTTP gave a specific number of connections as a
ceiling, but this was found to be impractical for many applications. As
a result, this specification does not mandate a particular maximum
number of connections, but instead encourages clients to be conservative
when opening multiple connections.

In particular, while using multiple connections avoids the "head-of-line
blocking" problem (whereby a request that takes significant server-side
processing and/or has a large payload can block subsequent requests on
the same connection), each connection used consumes server resources
(sometimes significantly), and furthermore using multiple connections
can cause undesirable side effects in congested networks.

Is it worthwhile to add the caveat;

Clients attempting to establish simultaneous connections SHOULD anticipate
the server to reject excessive attempts to establish additional connections,
and gracefully degrade to passing all requests through the successfully
established connection(s), rather than retrying.


Adrien de Croy - WinGate Proxy Server -