XHR Connection Length Advice

From RuntimeWiki

Jump to: navigation, search

Contents

Title

XHR Connection Length Advice

Detailed write-up

Description

See The Two HTTP Connection Limit Issue and Persistent Connections Issue

Why Is This Important?

See The Two HTTP Connection Limit Issue and Persistent Connections Issue

Solution

I propose that we have define a property called "durability" to the XMLHttpRequest object, that can be assigned a positive number (x >= 0) by authors that want to advise the user agent on how long they expect the given request to last. A low value indicates that the request is expected to be very quick and a high value indicates that the request is expected to take longer. The "durability" property should default to 1, and so a value of 1 indicated a request with an average length of time. The durability property can set and modified at any time before, during, or after a request. A user agent is not required to behave in any particular way in response to the durability property, it is simply a standard way for authors to provide information about how long the response will probably take so that user agents can utilize this information in making informed optimization decisions, and provide a means for intelligently avoiding indefinitely queued requests/responses.

There are no requirements for how the user agent responds to this property, but it is recommended that user agents use this information to help optimize pipelining and avoid potentially connection limiting. The lower the durability value, the faster the request is likely to receive a response, and therefore the corresponding connection is a better candidate for pipelining if that is enabled in the user agent. The higher the durability value, the slower the request is likely to receive a response, and therefore a high durability value indicates that the connection is a poor candidate for pipelining. A very high durability value (>100) indicates that the response may be so slow in coming that it may be advisable for the connection to not be counted against the two-connection limit.

This can be used by user agents to avoid the problem of responses becoming indefinitely queued due to being pipelined on a connection where a previous response is never finished.

Authors could also leverage user agents that follow the recommendations in the proposal to create high-efficiency duplex communication channels (by setting low durability values to attract pipelining).

Below is an example of usage of "durability":

var xhr1 = new XMLHttpRequest(); xhr1.open("GET","chat",true); xhr1.durability = 1000; // this response may take a long time to return, user agents may not want to pipeline here xhr1.send(null); .... xhr1.durability = 0.1; // now a fast response is indicated, this connection may be a good candidate for pipelining now var xhr2 = new XMLHttpRequest(); // the author has effectively recommend that this request be pipelined on the connection used by xhr1 xhr2.open("GET","resource",true); xhr2.send(null);

Once again this is not proposal for pipelining to be implemented through XHR, nor a requirement that connection limits be increased, it is merely a channel for advice to be passed that a user agent can utilize if it desires. There are a number of reasons why allowing XHR advice is better than completely deferring all advice to be provided by HTTP response headers:

1. The advice can be immediately available. Responses headers are not available until received from the server, and in the meantime, advice can be very relevant in helping to optimize pipelining. In particular, HTTP response advice simply can not solve the problem of pipelining requests behind long-lived responses resulting in indefinitely queued responses. If a browser is pipelining requests, and a response is long-lived, it may attempt to pipelining requests before receiving response headers indicating that pipelining is not a good choice with the current response. The browser simply has no information to suggest otherwise if it only comes through response headers.

2. Advice can be altered during the life of the request/response. A response header can only offer a single piece of advice, but XHR durability advice can change, and the durability value can be lowered if the author knows that a response will be received shortly. This can provide information that the user agent may not be able to determine.

3. If browsers implemented pipelining and observed the recommendations for pipelining, this opens the doors for true duplex communication on a single TCP channel. Server-initiated messaging techniques are essentially efforts to provide asynchronous duplex communication between the client and server. However, currently all mechanisms for this rely on two TCP connections, despite the fact TCP is fully duplex, and duplex communication is possible with HTTP as well. I believe we would be remiss in not looking to the future and considering how we can be moving towards a solution where authors can achieve duplex communication efficiently; on a single connection. This proposal provides that pathway. If there are any other mechanisms for doing this, I would love to hear about them, but I do not know of any, and all current techniques for server-initiating messaging (including the HTML 5 server-sent events) require two TCP connections for asynchronous duplex communication (I would definitely be more interested in HTML5 server-sent events if they did have some trajectory towards duplexity).

4. HTTP advice and XHR advice do need to be at odds. The proposal is to have a standard property that can be used for heuristics, and if HTTP adds a response header for advice, both sources of information can be used for further improving heuristics.

5. This advice is useful for more than just indefinitely long-lived responses (as used with server initiated messaging), but could be extremely useful in advising about responses that are known to take take a long time to be processed on the server, so user agents could avoid pipelining behind such requests.

6. Since this is simply an optional property for the sake of advice, JavaScript authors could immediately begin adding this advice to XHR requests, and browser vendors could experiment with different ways of observing the advice, at their own convenience, without having divergent APIs. Experience based on implementation then might possibly lead to more concrete requirements for observing the advice in the future.

Background material that request this feature

Discussion

In this section, the contributors should express their opinions about this feature request, such as providing particular technical analysis or describing in prose why this feature is important (or not). It is recommended that each contributor create his own level-3 sub-section (e.g., === Jon Ferraiolo Comments ===).

It is OK for others to insert comments within other people's sections, but as a courtesy please make sure that it is clear which part of the section is original and which section are annotative comments. For example, perhaps annotative comments would be colorized (e.g., enclosed by <span style="color:red">JON: Here is what I think about what you are saying.</span>).

Jon Ferraiolo Comments

Sounds like a good proposal to me. I'm not sure about the exact attribute name (durability) or the approach for the value of this attribute, but the general thrust of the proposal makes sense to me. The key thing is to provide a hint that gives information to browsers in order to deliver improved communications performance. This could be rolled out into the industry in two ways: (1) W3C specifies something that browsers start to implement, (2) one browser takes the lead and implements this proposal or something like it initially, and then the other browsers and W3C work out an interoperable standard.

Phase II Voting

More about this later.

Personal tools