Closed Bug 172861 Opened 22 years ago Closed 22 years ago

Limiting number of connections

Categories

(Core :: Networking, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: pfk, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529
Build Identifier: different

Some people (so also me) use massive tabbing with background loading.
Number of background TCP/IP connect should be possible to limit, if
limit is reached other connections are delayed and actually started when
an older connection is finished.

Number of connections should be limited by a per host base and also
the total number of connections should be limitable.

Example for modem:
  - per host: 32
  - total:    32

Example for T1:
  - per host: 48
  - total:   128

Example for T3:
  - per host: 64
  - total:   256


Reproducible: Always

Steps to Reproduce:
1.
2.
3.




This would also be more friendly for small web servers.
There *is* already a limit per server : see bug 132818 for more explanation and
the names of the preferences if you want to change them. about:config tells me
that the defaults are 8 normal connections per server, 4 persistent per proxy
and 2 persistent per server. You can also enable pipelining to make it a bit
more efficient (requests will spend less time in the queue).

Frank : you seem to file dozens of bug-reports these last few days (and you try
to reply by mail instead of by web), without looking for duplicates, or even
testing if they're valid. In this case you would have seen request to remove or
increase this limit for local downloads.

I'm closing this as WORKSFORME. You can reopen if you want to propose to change
the defaults. But the ones that you propose are much too high (have you doen any
tests to prove that these are really better ?), and might cause
denial-of-service attacks on webservers. Actually, my day-time job is for a
major telecommunications manufacturer, and I can tell you that we try to prevent
this kind of behaviour. It's catalogued as a DNS-attack, and your bandwidth will
be automatically be lowered. I'm working on systems like this, and I surely
don't want to encourage this behaviour. There's no reason to open 64 parallel
connections to 1 server, and expect that the end-result will be faster.
Increasing the total number of connections : ok, that would be more acceptable
(unless you're using a proxyserver).
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.