Re: Design Issue: Max Concurrent Streams Limit and Unidirectional Streams

responses inline


On Fri, May 3, 2013 at 2:35 PM, William Chan (陈智昌) <willchan@chromium.org>wrote:

> On Fri, May 3, 2013 at 6:20 PM, Roberto Peon <grmocg@gmail.com> wrote:
>
>> The biggest rub in Martin's suggestion is that, as a stream initiator, I
>> no longer know for how long I should keep the original "request" headers
>> around.
>> I view that as an annoying problem (I want every response to be
>> attributable to a request).
>>
>
> I spent time thinking about whether or not this was a problem. I certainly
> found it annoying, but it might be change aversion from SPDY. My mental
> reduction of this suggestion was the coupling of directions of the stream
> was moving out of the streaming layer to the application semantics layer.
> At the HTTP semantic layer, where you want a response for every request,
> the client can open a client=>server direction stream at the streaming
> layer and register a callback for the server=>client direction stream at
> the streaming layer. The client keeps the original request headers as long
> as it's expecting the response stream.
>
> I think there's a certain aesthetic layering cleanliness to Martin's
> suggestion in this way by moving the coupling out from a lower layer to a
> higher layer. I am still mulling it over. I also haven't thought through
> the server case, so I might have missed how this is annoying for them.
>

No argument there. Except for the issue with the lifetime of headers, it is
a very pretty design (the only thing you end up having to change is the
strict requirement on stream ID mentions being in monotonic order, which
we're loosening anyway for push). As a matter of fact this was one of the
ways we had discussed for SPDY/1 :)

In general any server/proxy/loadbalancer will wish to keep headers about
for the shortest time period possible as they typically represent either
the largest or a very large chunk of the state the server keeps resident.
It is possible to do fancy/complicated things to reduce this burden.. but
they're fancy/complicated :)

-=R