Sounds to me like this blog is describing pipelinging which is a standard part of HTTP 1.1...
What is HTTP pipelining?
Normally, HTTP requests are issued sequentially, with the next request being issued only after the response to the current request has been completely received. Depending on network latencies and bandwidth limitations, this can result in a significant delay before the next request is seen by the server.
HTTP/1.1 allows multiple HTTP requests to be written out to a socket together without waiting for the corresponding responses. The requestor then waits for the responses to arrive in the order in which they were requested. The act of pipelining the requests can result in a dramatic improvement in page loading times, especially over high latency connections.
Pipelining can also dramatically reduce the number of TCP/IP packets. With a typical MSS (maximum segment size) of 512 bytes, it is possible to pack several HTTP requests into one TCP/IP packet. Reducing the number of packets required to load a page benefits the internet as a whole, as fewer packets naturally reduces the burden on IP routers and networks.
HTTP/1.1 conforming servers are required to support pipelining. This does not mean that servers are required to pipeline responses, but that they are required to not fail if a client chooses to pipeline requests. This obviously has the potential to introduce a new category of evangelism bugs, since no other popular web browsers implement pipelining.
When should we pipeline requests?
Only idempotent requests can be pipelined, such as GET and HEAD requests. POST and PUT requests should not be pipelined. We also should not pipeline requests on a new connection, since it has not yet been determined if the origin server (or proxy) supports HTTP/1.1. Hence, pipelining can only be done when reusing an existing keep-alive connection.
How many requests should be pipelined?
Well, pipelining many requests can be costly if the connection closes prematurely because we would have wasted time writing requests to the network, only to have to repeat them on a new connection. Moreover, a longer pipeline can actually cause user-perceived delays if earlier requests take a long time to complete. The HTTP/1.1 spec does not provide any guidelines on the ideal number of requests to pipeline. It does, however, suggest a limit of no more than 2 keep-alive connections per server. Clearly, it depends on the application. A web browser probably doesn't want a very long pipeline for the reasons mentioned above. 2 may be an appropriate value, but this remains to be tested.
What happens if a request is canceled?
If a request is canceled, does this mean that the entire pipeline is canceled? Or, does it mean that the response for the canceled request should simply be discarded, so as not to be forced to repeat the other requests belonging to the pipeline? The answer depends on several factors, including the size of the portion of the response for the canceled request that has not been received. A naive approach may be to simply cancel the pipeline and re-issue all requests. This can only be done because the requests are idempotent. This naive approach may also make good sense since the requests being pipelined likely belong to the same load group (page) being canceled.
What happens if a connection fails?
If a connection fails or is dropped by the server partway into downloading a pipelined response, the web browser must be capable of restarting the lost requests. This case could be naively handled equivalently to the cancelation case discussed above.
The work that IBM did was over 10 years ago... and they were working on the library management system and creating a local system to view digital versions of documents that shouldn't be handled frequently. However none of that work translated to the web very well...
One thing I found humourous as I flipped through the TechTV photos was the warning on the outside of the box about opening it, and then once they did open it, the number of stickers insode with warnings and information that "technically" shouldn't be required if end users paid any attention to the outer sticker...
I don't think there is any requirement to speculate on why the buildings collapsed. To assume that we have ever built any thing to withstand the impact of a 767 airliner at 400mph+, an explosion of 6000 gallons of jet fuel and a resulting blaze that would be burning at 1500 degrees F. Is stupid and foolish. We don't build anything to that spec. Once the steel and concrete cracked, stressed and melted under those conditions, the weight above would have come down. Once that chain reaction starts - NOTHING will stop it. We were lucky they stood up for the better part of an hour.
I've also heard that one of the toy companies will soon be releasing a series of large bug-like toys that are robotic and specifically designed to be accessable and "hackable" by their owners.
Business 2.0 magazine recently had an article discussing some of the goings on at MSR. It can be found here:
http://www.business2.com/articles/mag/print/0,16 43,14731,FF.html
I think what this is trying to say, is, that if you are going to slam someone in an article don't publish it in Australia. They seem to claim that the article did appear in Australian based media. Thus the original publishing in New Jersey is moot. Question is... does that mean the just because someone in Australia opens the page on a US based server, that it is now "published" in Australia. I would doubt that.
Lots of good non-corporate content out there!
on
Seanbaby.com
·
· Score: 2, Informative
I think there is a large proliferation out there of non-corporate content creation sites scattered all over the web. By virtue of being non-corporate, they are just harder to locate unless you are told about it, or happen to pick it up in an off-beat search. For example, another great undiscovered content producer is www.digiclair.com which produces a mix of serious technology and gaming articles with rants and satire pieces. All good stuff, just not well known(til now;-) ).
The recording industry should focus on producing more CDs that are actually listenable from front to back rather than producing 95% of their full length CDs that have only 1 or 2 tracks that you can stand to hear more than once.
Maybe this should be taken to say that the "big money" recoding industry is putting out so much garbage that no one is buying it. How convenient to have a "pirate" scapegoat to defend the junk that commercial artists are producing these days - long live the underground!
As far as DDNS' usability goes. Keep in mind that DDNS is an option in Win2k - not a requirement. On my win2k advanced server running Release Candidate 1 of the beta code, you can still choose to run the regular DNS service. The advanatages of DDNS will likely make administrators want to move to it.
Slashdot Mirror
Took them almost 30 years, but they've done what he suggested in the review!
I say screw both - use SSH instead!
Volume drives down price.
It would likely be the buy-in of an auto manufacturer that puts the cost of this stuff through the floor!
It could be connected to a central vac type unit that 'pipes the heat right outta your office'!
Sounds to me like this blog is describing pipelinging which is a standard part of HTTP 1.1...
What is HTTP pipelining?
Normally, HTTP requests are issued sequentially, with the next request being issued only after the response to the current request has been completely received. Depending on network latencies and bandwidth limitations, this can result in a significant delay before the next request is seen by the server.
HTTP/1.1 allows multiple HTTP requests to be written out to a socket together without waiting for the corresponding responses. The requestor then waits for the responses to arrive in the order in which they were requested. The act of pipelining the requests can result in a dramatic improvement in page loading times, especially over high latency connections.
Pipelining can also dramatically reduce the number of TCP/IP packets. With a typical MSS (maximum segment size) of 512 bytes, it is possible to pack several HTTP requests into one TCP/IP packet. Reducing the number of packets required to load a page benefits the internet as a whole, as fewer packets naturally reduces the burden on IP routers and networks.
HTTP/1.1 conforming servers are required to support pipelining. This does not mean that servers are required to pipeline responses, but that they are required to not fail if a client chooses to pipeline requests. This obviously has the potential to introduce a new category of evangelism bugs, since no other popular web browsers implement pipelining.
When should we pipeline requests?
Only idempotent requests can be pipelined, such as GET and HEAD requests. POST and PUT requests should not be pipelined. We also should not pipeline requests on a new connection, since it has not yet been determined if the origin server (or proxy) supports HTTP/1.1. Hence, pipelining can only be done when reusing an existing keep-alive connection.
How many requests should be pipelined?
Well, pipelining many requests can be costly if the connection closes prematurely because we would have wasted time writing requests to the network, only to have to repeat them on a new connection. Moreover, a longer pipeline can actually cause user-perceived delays if earlier requests take a long time to complete. The HTTP/1.1 spec does not provide any guidelines on the ideal number of requests to pipeline. It does, however, suggest a limit of no more than 2 keep-alive connections per server. Clearly, it depends on the application. A web browser probably doesn't want a very long pipeline for the reasons mentioned above. 2 may be an appropriate value, but this remains to be tested.
What happens if a request is canceled?
If a request is canceled, does this mean that the entire pipeline is canceled? Or, does it mean that the response for the canceled request should simply be discarded, so as not to be forced to repeat the other requests belonging to the pipeline? The answer depends on several factors, including the size of the portion of the response for the canceled request that has not been received. A naive approach may be to simply cancel the pipeline and re-issue all requests. This can only be done because the requests are idempotent. This naive approach may also make good sense since the requests being pipelined likely belong to the same load group (page) being canceled.
What happens if a connection fails?
If a connection fails or is dropped by the server partway into downloading a pipelined response, the web browser must be capable of restarting the lost requests. This case could be naively handled equivalently to the cancelation case discussed above.
The work that IBM did was over 10 years ago... and they were working on the library management system and creating a local system to view digital versions of documents that shouldn't be handled frequently. However none of that work translated to the web very well...
perhaps we can even get some quantum scanners to locate the Taliban cowering in caves...
One thing I found humourous as I flipped through the TechTV photos was the warning on the outside of the box about opening it, and then once they did open it, the number of stickers insode with warnings and information that "technically" shouldn't be required if end users paid any attention to the outer sticker...
I don't think there is any requirement to speculate on why the buildings collapsed. To assume that we have ever built any thing to withstand the impact of a 767 airliner at 400mph+, an explosion of 6000 gallons of jet fuel and a resulting blaze that would be burning at 1500 degrees F. Is stupid and foolish. We don't build anything to that spec. Once the steel and concrete cracked, stressed and melted under those conditions, the weight above would have come down. Once that chain reaction starts - NOTHING will stop it. We were lucky they stood up for the better part of an hour.
I've also heard that one of the toy companies will soon be releasing a series of large bug-like toys that are robotic and specifically designed to be accessable and "hackable" by their owners.
Business 2.0 magazine recently had an article discussing some of the goings on at MSR. It can be found here:6 43 ,14731,FF.html
http://www.business2.com/articles/mag/print/0,1
I think what this is trying to say, is, that if you are going to slam someone in an article don't publish it in Australia. They seem to claim that the article did appear in Australian based media. Thus the original publishing in New Jersey is moot. Question is... does that mean the just because someone in Australia opens the page on a US based server, that it is now "published" in Australia. I would doubt that.
I think there is a large proliferation out there of non-corporate content creation sites scattered all over the web. By virtue of being non-corporate, they are just harder to locate unless you are told about it, or happen to pick it up in an off-beat search. For example, another great undiscovered content producer is www.digiclair.com which produces a mix of serious technology and gaming articles with rants and satire pieces. All good stuff, just not well known(til now ;-) ).
Craig.
The recording industry should focus on producing more CDs that are actually listenable from front to back rather than producing 95% of their full length CDs that have only 1 or 2 tracks that you can stand to hear more than once.
Maybe this should be taken to say that the "big money" recoding industry is putting out so much garbage that no one is buying it. How convenient to have a "pirate" scapegoat to defend the junk that commercial artists are producing these days - long live the underground!
As far as DDNS' usability goes. Keep in mind that DDNS is an option in Win2k - not a requirement. On my win2k advanced server running Release Candidate 1 of the beta code, you can still choose to run the regular DNS service. The advanatages of DDNS will likely make administrators want to move to it.