Maximum concurrent connections are limited (by an option in prefs.js I think). If there are 8 browser windows downloading something large (an image), a 9th window if told to request a page will behave as follows: Mozilla icon (top right) will animate. Cursor will be arrow and hourglass Statusbar shows "Done". When a connection becomes available for this window to use, the status bar will change to "Sending request..." The status bar message while waiting for available connection is wrong. Document loading is not done, it hasn't even started yet. It should show a sensible message that tells the user what Mozilla is actually doing.

right, this needs to be fixed. ideally it would be nice to give the new request highest priority, perhaps we could even suspend one of the other loads if the server supports byte-range requests and start on the new high priority load right away. this would probably be the most ideal solution. otherwise, we could try to come up with some sort of status message that would perhaps make sense to users.

I woulddefinitely not want a page left to load in the background to stall when I make a new window and a new request. In many cases, the reason why I open a new window is that I want to leave a page downloading in the background while I look for more info at the same time. Expanding this concept, the 8 connections limit can be easily reached. The current behaviour as I see it seem to be first come first serve when awaiting for new connections to be available is ok.

perhaps, but doesn't it seem logical to give higher priority to what the user is viewing? IMO we should try to better share the available bandwidth without overloading servers. that may mean suspending a background load until foreground items finish loading, or it may mean something else. but, given the limitations of HTTP, i'm not sure what that something else might be.

If it were like described in comment #3, what would be the purpose of multitasking and having processes run in the background? What would be the purpose to even have multiple browser windows or tabs at all? If foregrounds cuts off everything else!

i wasn't suggesting that multitasking would be defeated by this. indeed quite the contrary. my suggestion was just to put on hold those things happening in the background if it happens that those things prevent the current, visible page from being loaded at all. of course, if both can load simultaneously that is best, but there are real limits to how many connections we can have open at a time, so we must multiplex over those connections. that may mean suspending a background load until the foreground load finishes. afterwards, the background load can be continued right where it left off without the user noticing anything but a delay in loading the background page. how can this be a bad thing?

Like having x processes working at priority Normal, and when you start a new one, the other automatically are assigned priority Idle? It's not fair. What if I have 8 (current limit) of downloads and I open the 9th page, and then continue opening new pages until I arrive at 15? What if I get at 16 and more? What then? pause all other connections because the page I have displayed last has many images in it? What I said in the previous message pops up right away. I my case this scenario is quite close to the normal everyday use. Suspending background loads is CONTRARY to the very concept of background loads. While those pages load in the background, I am doing something else -> more efficiency. I am looking for more info, I may open new windows to look for other info. Just as the data transfer through TCP/IP goes through my link multiplexed for each thread that I have loading. I know it slows down, but having a thread pause in the background is the last thing I would want it to do. What if the page I have in fg. pauses others, but I change focus to one of those paused pages, what then? it will resume and pause the one that cause it to pause? Confusion, confusion, confusion. Single thread tasking (ok, multiplied by 8 but still...)? No, thank you, I would rather go back to the old DOS instead.

dude! your missing the point. if a background load is hogging all the connections to a server, then you can't open a new window to look for other information on the same server. that's the state of things today. i'm not suggesting suspending background loads just because they are in the background. i'm only saying that if a foreground load needs to talk to a server that is already being hit heavily by a background load, then it makes sense to suspend that background load so the foreground load can proceed.

On the other hand, what makes you think that new windows must definitely hit the same server? What if I do a google search and open 20 hits in rapid succession in new windows or tabs. They will hit a large variety of servers. And if I can afford the bandwidth, I get limited by the browser? How do you propose to pause? send a rst and then resume by making a new connection and asking a byte range? Again, if I constantly switch between open browser windows, then connections will pause and resume as each window gets focus? This may put a lot of additional load on the network with the packets needed to do so. If the solution proposed is that above, it will put a lot of needless traffic onto the network. Or another way: stop sending ack's? If you are behind a proxy, after some part of the download has already arrived, the proxy will finish the download anyway, regardless of what the user does, so again, the server will still be under large load, regardless of what mozilla does. If someone plan to play this pause strategy with connections, PLEASE make it configurable so the user can turn it off. It will definitely be the first thing I will do, and continue to consider it a bad idea.

the limit on the number of different websites is much higher. the max number of simultaneous connections is 24 (unless you are connecting via a proxy server in which case it is much lower).

The limit you are talking about should definitely not depend on wheather one uses a proxy or not. If the proxy whishes to impose no. of active connections, it should do so itself.

would be nice, but that's unfortunately not the way proxy servers work. gecko is supposed to limit the number of connections to a proxy server to avoid congestion / overloading the proxy server. opening many connections may seem like a good thing from the perspective of the user, but if everyone's webbrowser opened an unlimited number of connections, the internet would buckle under the load, making performance much much worse for a single user.

With squid I can limit the number of simultaneous tcp connections a client makes with the proxy and returns a denied page if more are open.

yes, and wouldn't it be fun if several million browsers all tried to open up an additional connection to your proxy server ;-) seriously though... consider the ISPs out there. they depend on the hard limit imposed by not only existing browser implementations but also recommendations made in RFC 2616. this is asking for trouble.

It still isn't fair that using a proxy the number of connections regardless of destination, should be the same as the limit for connections to a single destination. And secondly, if these limits are configurable (prefs or at least in the *.js files and documented), i will drop my objections. I mean : max conn. limit same site max conn. limit any site max conn. limit using a proxy (same site, any site) new connection strategy: first come - first serve, priority to foreground when new connections available, pause/halt for later resume other connections so that foreground may download. I will definitely modify these. Second, excluding all other possible issues, I still have much better performance navigating with Netscape 4.75 and even better with Netscape 3 in my usual pattern of browsing, which is 10-30 open windows and at least half of them loading something.

they are all prefs... search all.js for network.http.* ... and make whatever changes you like to your own prefs.js :)

#8 - Not all proxy servers complete a download if the client cancels the connection. The limitation of total connections to a proxy is prudent, not all proxies have connection limit checks in their code. Some proxy farms are highly distributed and would not be able to tell if you opened too many connections.

Thanks for the prefs suggestion. Though not related, but in the line of the discussion here : I know Netscape 4.7 when loading a page with many images and that spans over several screen size pages (pagedn several times to end of document). When in loads the images in this page, it favours for new connections (only) the images that are in the currently visible part of the document. How does mozilla consider this (if at all) since I haven't been able to determine it yet.

mozilla's transaction queue is first-in, first-out. in other words, subsequent page loads (and images) get lowest priority.

-> default owner

h2