> What Netscape has done, in a sense, is to abrogate its responsibilities
> for efficient behavior at the expense of the network at large and those
> who choose to operate http servers.
>
We (people running servers, especially those running commercial ones!)
should be happy that the end users will be getting documents faster.
Some would call this progress! Bandwidth can be bought easily enough
and making good use of it, as NetScape and WebExplorer do, should be
seen as something good. Server overload (if you are indeed running
a *very* slow very) is a good problem to have in my opinion. Because
it can be fixed easily. Fixing clients is *much* harder!
> Background:
>
> Netscape retrieves the document and as it reads it --character by
> character-- immediately initiates requests for all of the graphical
> elements on the document as they are seen, opening a socket request for
> each element. Those requests are fulfilled on seperate virtual circuts
> and the data then comes crashing down the pipe, to be displayed on the
> user's screen. (Marc, please correct me if I am wrong.)
>
I think "crashing down the pipe" is a biased way of putting it. ;)
In a non-threaded request data would still be "crashing down the pipe"
due to the fact that most serious HTTP servers are connected by higher
bandwidth than the end user.. Magnitudes higher at that.
> Effects on Network Infrastructure:
>
> What this does, besides making the retrieval appear to operate faster to
> the user, is to create a very bursty network usage profile.
>
Yes! and from what I've seen, HTTP is very, very good at "bursty".
> For example, it is very possible, for a single Netscape document request
> to max out a full T-1 for a small, but measurable period of time. This
> will, I suspect, cause Netscape initiated web traffic to operate faster
> *AT THE EXPENSE* of all the other network services.
>
The same is true for other net services.. It's possible for FTP
to max out any connection speed for a measurable period of time
as well, what else is new?
> Effects on HTTP Servers:
>
> This is also very server/provider unfriendly because your server has now
> been turned from serving numerous requests at the same time to
> potentially serving a single "virtual" request.
>
What's the difference? If the user is going to access your HTML
document (let's say 4 independent requests, 3 of which are graphics)
what is the overall difference in server load? In either situation
your server will experience 4 independent requests. Those requests
are not all batched up and sent once using the old way. For all
the techies, please excuse the simplification:
Old way:
S: Hey, Mr. HTTPD sent me the HTML text.
C: ok.. Got it.
S: Hey, Mr. HTTPD sent me the GIF.
C: ok.. Got it.
S: Hey, Mr. HTTPD sent me the GIF.
C: ok.. Got it.
S: Hey, Mr. HTTPD sent me the GIF.
C: ok.. Got it.
New way:
S: Hey, Mr. HTTPD sent me the HTML text.
S: Hey, Mr. HTTPD sent me the GIF.
S: Hey, Mr. HTTPD sent me the GIF.
S: Hey, Mr. HTTPD sent me the GIF.
C: ok.. Got it..
C: ok.. Got it..
c: ok.. Got it..
C: ok.. still getting it.. ;)
As we all know, the old way makes you wait until the client gets
everything before showing *you* the person anything. Whereas the
new browsers allow you to view the results from the initial
requests. Again, this seems like a cool way to do things, it's
just like the threads in an OS. Why should a process wait for
some other subprocess to exit before it can finish its own work
or start another subprocess? It should be plain to see the
advantages of this..
> Under Sun/OS, the kernel is preconfigured to provide only 32 IO slots
> per process. When your server (either inetd if you run under that
> mechanism or the actual www server itself) receives the requests which
> comprise a document with 16 graphical elements on it, that single user
> has consumed half of the available IO slots for the length of time it
> takes to fulfill the request. (Yes, I realize you can up the IO slots
> and remake the kernel, that is not the point.)
>
So based on the above, if 32 people access your machine at once
then your server crashes? Some how I don't think that's the case.
> This pushes the performance bottleneck squarely on the shoulders of the
> network infrastructure and the service providers which, in a non-metered
> network and in the current non-pay environment of the web, is grossly
> irresponsible (IMHO).
>
I think "grossly irresponsible" is a bit strong. People with 14.4
slip/ppp definately are NOT saying that netscape or WebExplorer are
"grossly irresponsible"..
This is an interesting discussion topic and I'd love to hear why
multi-threaded server accesses are so bad.
>
> </rr> (Robbing Peter to pay Paul.)
>
keith (Giving Paul a bill.)
_____ _ |\ o|\ | ______ I n t e r n e t P r e s e n c e & Publishing
| / | \ || \ |\ |__ | 1700 World Trade Center ofc: 804.446.9060
| \_ |_/.||_/.| \|\_ | Norfolk, Virginia 23510 fax: 804.446.9061
| | www: http://www.ip.net/ email: keith@tcp.ip.net