Re: Optimizations vs Functionality vs Architecture

On 22.08.2012 15:03, James M Snell wrote:
> On Tue, Aug 21, 2012 at 7:43 PM, Amos Jeffries wrote:
>
>> [snip]
>> * it exists and is already well defined.
>> * it has existing implementations we can leverage.
>> * it operates on next-hop independent of any connection complexity 
>> and
>> most legacy software.
>> * ANY hop can attempt to optimize/Upgrade.
>> * it has a safe failure mode resulting in 1.1 being used.
>> * worst-case cannot be worse than standard 1.1 performance (since 
>> failure
>> ist to use 1.1).
>>
>> The downside is all in the implementation code specifics. ie it is 
>> *our*
>> problem to find easy implentation methods, not impacting the users.
>>
>>
> Ok.. so how exactly would this work... suppose all I want to do is a 
> simple
> HTTP GET. Am I going to send a 1.1 GET request with an Upgrade header 
> and
> wait for the response to come back as HTTP/2.0 or do I send an HTTP 
> 1.1
> OPTIONS request with upgrade, check to see if 2.0 is supported, then 
> send a
> HTTP 2.0 GET request second?

(Just replied to this in response to the other email about HEAD 
requests.)

> In the former case, assuming we are indeed
> using SPDY, we won't have an established SPDY Stream yet within which 
> to
> send the response so I'm not quite sure how that's suppose to work. 
> In the
> latter case, we're wasting one RTT to upgrade the request (which,
> thankfully, should only need to happen once per connection...).

Which is reason #1 why server-initiated stateful sessions don't work on 
a pull architecture. SPDY session flow control needs to be thrown away 
and re-designed to use implicit instead of explicit setup. The 
network-friendly draft had implicit hop-by-hop session creation and 
teardown based on WebSockets - with the benefits described in mobility 
draft - it works more efficiently than SPDY stateful session handshake 
is capable of. We picked it per-request to keep teh 1-to-1 
request/response mapping of HTTP/1 but there is no technical reason taht 
cannot be extended to handle future server-push or client-push features.

Essentially a session can be created on client request receive, and 
persists as long as necessary with associated "state". 1 response or N 
responses it does not matter. But never mind that for now. I'll pull out 
the details when we get as far as flow control designs.

Amos

Received on Wednesday, 22 August 2012 03:29:07 UTC