Closed Bug 170668 Opened 22 years ago Closed 9 years ago

Status bar should show other message while waiting for available connection

Categories

(Core :: Networking: HTTP, enhancement)

Product:
Core
Component:
Networking: HTTP
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: andrixnet, Unassigned)

Details

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.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Windows 95 → All
Hardware: PC → All
Target Milestone: --- → mozilla1.3alpha
Summary: Status bar should show other emssage while waiting for available connection → Status bar should show other message while waiting for available connection
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.
Severity: trivial → enhancement
Priority: -- → P5
Target Milestone: mozilla1.3alpha → Future
-> default owner
Assignee: darin → nobody
Status: ASSIGNED → NEW
Target Milestone: Future → ---
h2
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.