Re: Implementation Notes on Server Push

[James M Snell <[e-mail]>]

On Tue, May 14, 2013 at 5:08 PM, Roberto Peon <[e-mail]> wrote:
> inline
>[snip]
>>
>> > There is language in the spec that if the client resets a stream that it
>> > implicitly resets any associated streams too. That was complicated to
>> > implement and pretty much broke my stream state model internally - while
>> > researching it it appears that mod_spdy and chrome don't implement it at
>> > all. The spec has an editorial note about removing that feature and I
>> > favor
>> > that removal.
>>
>> I added that text, so I tend to agree. :)
>
>
> I agree it should be removed. If we need a mechanism to close many streams,
> we can add a new opcode type instead of some implicit requirement.
>

If I recall correctly, everyone seemed to be nodding in agreement on this one.

>>
>>
>> > I found flow control for pushed streams immensely helpful. It lets the
>> > client bound how much data can be pushed before there is a local GET
>> > matched
>> > up with that. Relatedly, I changed my default SETTINGS window size from
>> > a
>> > ~infinite value to be a smaller push-apropos value and then pipelined a
>> > window update with each odd SYN_STREAM to make pulled streams ~infinite
>> > again while preserving the smaller limit for push and this worked fine
>> > with
>> > all existing servers to my pleasant surprise. That seems to mean at
>> > least
>> > the spdy/3 windowing mechanism is simple enough for people to get right.
>>
>> That's interesting.  Do you believe that it would be worthwhile
>> splitting the initial window size setting in two?  One for streams I
>> initiate, one for streams you initiate?  That would save you a window
>> update on every new stream.
>>

"Splitting the initial window" seems wrong to me. Of course, I don't
have a better suggestion at the moment, but if I did I'm not certain
it would be this ;-)

[snip]

- James