Why do Java programmers always want to complicate things beyond any recognition ?
Maybe we should just rename Java to CTBAR (like FUBAR) ?
With all their abstraction layers and after refactoring, they don't even know what the system is really doing.
I see this time and time again, the code is doing everything double, triple times or a 100 times, because it is hidden behind some kind of abstraction layer and they can't get to it or don't see what they are really doing.
Is isn't really Java that is at fault here, it is mostly the programmers, it is their style. It tends to be the same kind of programmer which had the same kind of education. For some reason you can't explain it to them either.
Actually Adobe isn't all that interrested in Flash, it is just a technology they inherited when they bought Macromedia.
Just an few examples, Adobe worked many, many years on SVG. Supposedly they did a lof of fonts work for HTML5. They have a Flash2HTML5 convertor now (ok, just a first version which only supports a few things).
And only handout IPv4 to users that request it (pay extra), why ? Because the manufacturers of network-hardware for mobile phone networks ask you to pay 2 times when you want IPv4 and IPv6. So the profit margin is all gone. So they'll eventually do anything to move most users over to IPv6 and translate that to IPv4 where needed.
First thing that will happen is RIPE, ARIN, AfriNIC and LACNIC will suddenly get more customers and people from Asia will just IP-addresses from an other RIR, after people will start to pay for transfer of IPv4-addresses from one ISP to an other.
Atleast RIPE and ARIN have a similair policy as APNIC, I think.
It includes a presentation about bufferbloat from Jim Getty and a presentation by Mike Belshe from Google SPDY, HTTP-concurrent connections, HTTP-pipelining is mentioned in both and SCTP is mentioned in the SPDY-presentation.
As you will make out from the SPDY presentation is SCTP and HTTP-pipelining have deployment issues. But don't think SPDY does not have any. But from the bufferbloat presentation you will notice there are a lot of problems deploying IP on broadband and wifi anyway.
As I thought Secure-by-default (HTTPS) is a actually design-goal of SPDY, which HTTP-pipelining and SCTP obviously don't address directly.
The point was, most pages are to small to saturate the multi MBit network connections people have.
This isn't about limited bandwidth, it is about an abondance of bandwidth. Most people don't have HTTP-pipelining turned on because of buggy webservers and proxyservers, thus the browser needs to open more TCP-connections and the request/response is small enough to not 'completely open' the TCP-window for all these TCP-connections.
Now with HTTP pipelining or SPDY (not sure what you mean with reodering).
What happends when you visit a webpage ? You open a TCP-connection, you send one request. The webpage gets generated dynamically on the server. A smart webdeveloper would make sure part of the HTML is already pushed to the browser, the browser can see it needs to download a CSS-file, it will send a request to the server.
When you have HTTP-pipelining, you wait for the first response to complete before you get the response of the second request, unfortunately that first request takes the most processing time on the server and does not sature the TCP-connection, because they look something up in a database or whatever they do.
With SPDY the server can immediately respond to the second request before the HTML-page was downloaded completely. Because the second request is handled immediately, the TCP-window is increased earlier as well.
I'm, among other things, a webdeveloper and optimising website performance is one of the things I'm involved with.
When you get to a certain point, I've found that when many parts of the page are downloaded at first visit the browser needs to open more connections.
But opening more connections means doing more TCP-handshakes (which is a big problem when the latency between client and server is higher) and starting new TCP-slowstart processes. It turns out that a lot of the time a new TCP-slowstart is counter productive because files are small, it will take a number of requests over that TCP-connection to get some advantage of the bandwidth available to the user. Also because there is an obviously small delay between request/response. You are waiting that means this will also impact the time TCP-slowstart opens up the window proper. But if you have one TCP-connection, with many requests multiplexed the window uses by TCP-slowstart opens up a lot faster and you take full advantage from the bandwidth.
I think this is where most of the performance gain comes from.
And yes, you loose more when you have a dropped connection, but I don't think it is very prevalent. I haven't checked. But you can 'always' re-send a request with a range-header to get the part starting from the point where the connection was dropped.
Also with normal HTTP you need to use several TCP-connections when downloading things at the same time, so you get the overhead of TCP-slowstart. And don't say why do we have TCP-slowstart, trust me, you want it.
The old technology isn't universally supported and can only fallback by disconnecting. That is why it is not on by default.
SPDY works faster than just using pipelining it needs to 'upgrade' where available thus it is backwardcompatible.
Some other people do seem to care about more performance, so they work on this. Google has almost 25,000 people working for them, they have a few people working on SPDY. And not fulltime.
Pipelining isn't used because it is incompatible with some older servers and I think some proxy servers.
Also TCP/SSL/TLS handshakes are per connection, not request. But SPDY just needs the one connection, a modern browser when visiting some sites can open up to 20+ connections. That is a lot of unneeded overhead. Although you only get 20+ when you use something like 5 different domains, so with SPDY you would still be using 5 connections one per domain.
(the numbers are a bit made up, but gets the point across. Firefox 4 has a default setting of 15 connections per server)
The people working on SPDY submitted or working on atleast 3 different drafts for different changes to the IETF for backwardcompatible changes (SSL/TLS False start, HTTP-header for upgrade-to-SPDY and SPDY) that I know of.
1. SPDY uses 1 TCP-connection, instead of many. Which makes it faster. The time to establisch a new TCP-connection is a lot of overhead when you visit a webpage which has many small elements on it. It also has a big advantage when using HTTPS. Again because you just use the one TCP-connection (no extra SSL-connections to establish):
2. It is backwardscompatible and doesn't need any operating system changes like SCTP or different firewall settings and so on.
Yes, I know backwardscompatiblity is a big issue on the internet, but we have to live with it.
3. I think they also submitted their proposed changes for HTTPS to the IETF, like False-Start which helps establish HTTPS (and thus SPDY) connections faster, I think it saves one round-trip.
SPDY does not make ads cache more or less, any browser that does or would implement SPDY already does caching for HTTPS correctly (it adheres to what the creator of the webpage specied in the headers).
Slashdot Mirror
Then why would it not run under Windows XP ?
Active Desktop anyone ? As it was called in Windows 95, 98 and so on. Not sure how Microsoft calls this on Windows XP.
On Windows XP: Display Properties -> Desktop-tab -> Custimize Desktop -> Web-tab -> New
Why do Java programmers always want to complicate things beyond any recognition ?
Maybe we should just rename Java to CTBAR (like FUBAR) ?
With all their abstraction layers and after refactoring, they don't even know what the system is really doing.
I see this time and time again, the code is doing everything double, triple times or a 100 times, because it is hidden behind some kind of abstraction layer and they can't get to it or don't see what they are really doing.
Is isn't really Java that is at fault here, it is mostly the programmers, it is their style. It tends to be the same kind of programmer which had the same kind of education. For some reason you can't explain it to them either.
As Adobe puts it, it is a tool for converting 'existing Flash content' to HTML5.
Adobe does have a bunch of HTML5 tools coming up and ( some free and some not) add ons to existing tools.
Actually Adobe isn't all that interrested in Flash, it is just a technology they inherited when they bought Macromedia.
Just an few examples, Adobe worked many, many years on SVG. Supposedly they did a lof of fonts work for HTML5. They have a Flash2HTML5 convertor now (ok, just a first version which only supports a few things).
A lot of mobile phone network operaters in the US are migrating to IPv6 with NAT64:
http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#NAT64
And only handout IPv4 to users that request it (pay extra), why ? Because the manufacturers of network-hardware for mobile phone networks ask you to pay 2 times when you want IPv4 and IPv6. So the profit margin is all gone. So they'll eventually do anything to move most users over to IPv6 and translate that to IPv4 where needed.
First thing that will happen is RIPE, ARIN, AfriNIC and LACNIC will suddenly get more customers and people from Asia will just IP-addresses from an other RIR, after people will start to pay for transfer of IPv4-addresses from one ISP to an other.
Atleast RIPE and ARIN have a similair policy as APNIC, I think.
If you are willing to listen to a bunch presentations in bad audio I would really suggest this:
http://ietf80streaming.dnsalias.net/ietf80/ietf80-ch4-wed-am.mp3
It includes a presentation about bufferbloat from Jim Getty and a presentation by Mike Belshe from Google SPDY, HTTP-concurrent connections, HTTP-pipelining is mentioned in both and SCTP is mentioned in the SPDY-presentation.
As you will make out from the SPDY presentation is SCTP and HTTP-pipelining have deployment issues. But don't think SPDY does not have any. But from the bufferbloat presentation you will notice there are a lot of problems deploying IP on broadband and wifi anyway.
As I thought Secure-by-default (HTTPS) is a actually design-goal of SPDY, which HTTP-pipelining and SCTP obviously don't address directly.
The point was, most pages are to small to saturate the multi MBit network connections people have.
This isn't about limited bandwidth, it is about an abondance of bandwidth. Most people don't have HTTP-pipelining turned on because of buggy webservers and proxyservers, thus the browser needs to open more TCP-connections and the request/response is small enough to not 'completely open' the TCP-window for all these TCP-connections.
Now with HTTP pipelining or SPDY (not sure what you mean with reodering).
What happends when you visit a webpage ? You open a TCP-connection, you send one request. The webpage gets generated dynamically on the server. A smart webdeveloper would make sure part of the HTML is already pushed to the browser, the browser can see it needs to download a CSS-file, it will send a request to the server.
When you have HTTP-pipelining, you wait for the first response to complete before you get the response of the second request, unfortunately that first request takes the most processing time on the server and does not sature the TCP-connection, because they look something up in a database or whatever they do.
With SPDY the server can immediately respond to the second request before the HTML-page was downloaded completely. Because the second request is handled immediately, the TCP-window is increased earlier as well.
I would like to address point 2.
I'm, among other things, a webdeveloper and optimising website performance is one of the things I'm involved with.
When you get to a certain point, I've found that when many parts of the page are downloaded at first visit the browser needs to open more connections.
But opening more connections means doing more TCP-handshakes (which is a big problem when the latency between client and server is higher) and starting new TCP-slowstart processes. It turns out that a lot of the time a new TCP-slowstart is counter productive because files are small, it will take a number of requests over that TCP-connection to get some advantage of the bandwidth available to the user. Also because there is an obviously small delay between request/response. You are waiting that means this will also impact the time TCP-slowstart opens up the window proper. But if you have one TCP-connection, with many requests multiplexed the window uses by TCP-slowstart opens up a lot faster and you take full advantage from the bandwidth.
I think this is where most of the performance gain comes from.
And yes, you loose more when you have a dropped connection, but I don't think it is very prevalent. I haven't checked. But you can 'always' re-send a request with a range-header to get the part starting from the point where the connection was dropped.
Also with normal HTTP you need to use several TCP-connections when downloading things at the same time, so you get the overhead of TCP-slowstart. And don't say why do we have TCP-slowstart, trust me, you want it.
With SPDY you don't need all these connections.
The old technology isn't universally supported and can only fallback by disconnecting. That is why it is not on by default.
SPDY works faster than just using pipelining it needs to 'upgrade' where available thus it is backwardcompatible.
Some other people do seem to care about more performance, so they work on this. Google has almost 25,000 people working for them, they have a few people working on SPDY. And not fulltime.
I wouldn't say 1 second, but more like 1 or 5 minutes.
You might not need to book, there are also many presentation-videos (among many from Crockford) on this page:
http://developer.yahoo.com/yui/theater/
If you prefer that over reading.
That is why they are working with the IETF, not on their own. They have had a few draft on their site for over atleast one and a half year.
It isn't the browser that has problems with pipelinging, it is some old (proxy)servers.
Pipelining isn't used because it is incompatible with some older servers and I think some proxy servers.
Also TCP/SSL/TLS handshakes are per connection, not request. But SPDY just needs the one connection, a modern browser when visiting some sites can open up to 20+ connections. That is a lot of unneeded overhead. Although you only get 20+ when you use something like 5 different domains, so with SPDY you would still be using 5 connections one per domain.
(the numbers are a bit made up, but gets the point across. Firefox 4 has a default setting of 15 connections per server)
Yeah, I was thinking about that later.
I actually think not that many people actually still use proxies.
It is kind of funny, because this is in Chrome. Thus it is in Chromium, thus it is already in the open.
And the website has a whitepaper trying to explain it and lists all the drafts being worked on for submissing to the IETF:
http://www.chromium.org/spdy
http://www.chromium.org/spdy/spdy-whitepaper
http://www.chromium.org/spdy/spdy-protocol
It is the summary and article that are wrong.
SPDY has a draft and they already sumitted to other drafts to the IETF.
I don't know why you are rambling on about this.
The people working on SPDY submitted or working on atleast 3 different drafts for different changes to the IETF for backwardcompatible changes (SSL/TLS False start, HTTP-header for upgrade-to-SPDY and SPDY) that I know of.
Actually the article and summary are wrong, this has been part of the Chromium project from the start and always was.
1. SPDY uses 1 TCP-connection, instead of many. Which makes it faster. The time to establisch a new TCP-connection is a lot of overhead when you visit a webpage which has many small elements on it. It also has a big advantage when using HTTPS. Again because you just use the one TCP-connection (no extra SSL-connections to establish):
http://www.chromium.org/spdy/spdy-whitepaper
2. It is backwardscompatible and doesn't need any operating system changes like SCTP or different firewall settings and so on.
Yes, I know backwardscompatiblity is a big issue on the internet, but we have to live with it.
3. I think they also submitted their proposed changes for HTTPS to the IETF, like False-Start which helps establish HTTPS (and thus SPDY) connections faster, I think it saves one round-trip.
SPDY does not make ads cache more or less, any browser that does or would implement SPDY already does caching for HTTPS correctly (it adheres to what the creator of the webpage specied in the headers).
You mean Windows 2000 already does this.